При неоперативном проведении УТ не проверяет остатки.
Вижу множество аргументов ПРОТИВ этого.
Но есть ли аргументы ЗА?

вопрос по V8!

Да есть такие дело. Супер не правда ли ))

Думаю стоит ждать новую редакцию УТ либо писать. Франчи тоже возмущены очень.

(0) Есть. Один. Повышение быстродействия.

Я считаю версию, что документы формируют всегда оперативно и никогда не правят потом идиалестическим бредом... Закоментарить строки

// Проверка осатков при оперативном проведении.
Если РежимПроведения = РежимПроведенияДокумента.Оперативный Тогда
    НаборДвижений.КонтрольОстатков(Это....
....
конечно не сложно, просто думала, что в них есть некий глубинный смысл...

(4) Для полного быстродействия тогда стоит вообще отменить перепроведение
Раз провелось - все, больше кривыми ручками не лазить!

(5) Закомментарить условие про оперативность, конечно, не сложно. Чуть сложнее (точнее муторнее) во всех запросах прописать моменты времени в параметрах.

в правах запретить проводить неоперативно

(7) упс... А я не в теме! Остатки берутся не на момент времени?
Ща буду смотреть...

(8) это просто невозможно.
Некоторые расходные документы формируют днем позже.

И что ты этим хочешь добиться?

(9) там надо править модули регистров. Я в свое время так попался, просто закоментировав строки :))

(0) а смысл что-то контролировать при неоперативном проведении? последущие расходы могут свести на нет весь твой контроль и все равно заминусовать остатки.

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

(7) (9) Уже вижу, что не так все просто! Спасибо, что предупредили.

(13) не бардак, а условия проведения отчетов о розничных продажах с пос-терминалов.
А отрицательные остатки легче выявлять при проведении документов, чем потом отлавливать документы без себестоимости!

(15) а при чем здесь "неоперативное проведение"?
вы в pos-ах закрываете смены через день?

(15) не без себестоимости, а дающие отрицательный остаток

(16) они смену с терминала на след. день привозят.

(0) по правильному, нужно перепроводить сразу же всё, после нарушения последовательности. как уже сказали (4) - это будет полнейший тормоз, иногда, просто невозможный (документ двухгодичной давности, типа). Посему - это необходимое зло. по другому, просто невозможно при существующей идеологии УТ.
В аксапте - сторнирование для этого. Только что делать с итогами за прошедшии отчётные периоды?

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

"При этом контроль остатков остаётся на усмотрении "и тэдэ и тэпэ  - с саппорта 1С.
я не стал трогать. оставил как есть.
по причинам:
1. нех лазить в закрытый период. Только с разрешения шефа.
2. зачем туда лазить? делать сторно? если в "+", То необходимо только перепроведение документов.
3. если лишнего наприходовали.. (а ситуация с "-" может возникнуть по поему только в это случае) спрашивается что тогда переместили/продали.. воздух что ли?

Самое грамотное решение приняла 1С - не контролировать ничего при неоперативном проведении. Залезая назад, для нормальной работы надо контролировать не только прошлые, но и будущие документы. Это ужас просто! Так что грамотнее просто отключить контроль.

(22) ОК. Я согласна, что это возможно, когда все документы выписываются в системе в режиме on-line.
Но такой возможности нет:
1) Отчеты о продажах с посов принимают на следующий день;
2) Приходные документы исправляют за вчерашний день;
3) После каждого нарушения последовательности восстанавливать - хаха нереально конечно, в базе одновременно работают 40-60 пользователей;

Пока есть только такая идея:
Проверять остатки в модуле формы перед записью, чтоб проверка не происходила при перепроведении.

(23) "Проверять остатки в модуле формы перед записью" - ну да, ну да. Если одновременно несколько пользователей зафигачат списание по одной и той-же позиции, то минусы полезут всеравно.
Лучше ночь восстанавливать последовательность.

На ИТС :"как правило проведение задним числом опперация редкая и осмысленная "

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

Но время то идеть. Не стоит на месте.

(27) Вот нашелся человек, который меня понимает!

Себестомиость в регламент. Однозначно.

Раз в месяц  :)

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

(0) Я вот тоже такую тему поднимал: v8: Стоит ли контролировать остатки при неоперативном проведении документа? Включил неоперативный контроль, на следующий же день попросили отключить, вот так-то...

(29) Себестоимость в регламент - неплохое предложение. Но. Если есть доки делающие минусы - никакой себестоимости не получится.

Как предотвратить в общей массе эти минусы - вот концептуальный вопрос!

Идеи типовой УТ не прокатывают.

(33) Ну например, запретить проведение задним числом

Как предотвратить в общей массе эти минусы - вот концептуальный вопрос!

Концептуальный вопрос - это то , что для продажи чего либо материального необходимо сначала купить что либо маериальное. Это вид деятельности диктует все сложности.Проще конечно продавать не материальное. Т.е. то чего в имущественном выражении нет.

(20)
"(0) Идеология такая - проведение задним числом - это уже свершившийся акт и смысла в проверке остатков нету."

Смысл есть... например, на тот момент просто не было товара на складе....


(22)
"Залезая назад, для нормальной работы надо контролировать не только прошлые, но и будущие документы. Это ужас просто! Так что грамотнее просто отключить контроль."

Это - безграмотнее. НО ПРОЩЕ.... Ибо свою головную боль запихиваем в задницу пользователя и пусть он типа трахается...
   А документы действительно надо проверять.... Если ты сообразишь, как это делать быстро (пересчет) - тогда взлетишь....



(33) Купи идею... Продам недорого, баксов за 500...

(20)
"(0) Идеология такая - проведение задним числом - это уже свершившийся акт и смысла в проверке остатков нету."

Смысл есть... например, на тот момент просто не было товара на складе....


(22)
"Залезая назад, для нормальной работы надо контролировать не только прошлые, но и будущие документы. Это ужас просто! Так что грамотнее просто отключить контроль."

Это - безграмотнее. НО ПРОЩЕ.... Ибо свою головную боль запихиваем в задницу пользователя и пусть он типа трахается...
   А документы действительно надо проверять.... Если ты сообразишь, как это делать быстро (пересчет) - тогда взлетишь....



(33) Купи идею по предотвращению минусов.. Продам недорого, баксов за 500...

(34) Объясняла уже, что нельзя запретить проведение задним числом. Незачет.

(20)
| "(0) Идеология такая - проведение задним числом - это уже свершившийся акт и | смысла в проверке остатков нету."

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

(39) Так ты же написала про контроль ПриЗаписи - это неустраивает?

(40) ошибка - ПередЗаписью, конечно.

Контроль ПередЗаписью - это обсуждаемый вариант.
Я не писала, что не устраивает, есть недостатки, что несколько пользователей могут списать одни остатки.
Но! Процент документов ушедших в минус уменьшится на порядки!

можно вообще предотвращать...

(43) Как?...

(42) Какие проблемы - проверяй в ОбработкеПроведения. Тогда минусов не будет. Но могут быть блокировки с ошибками транзакци.

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

Попробуй понять. Я даже не могу поднимать разговор о изменении документооборота и регламентов. Над этим работали топ-менеджеры. Программист нужет для автоматизации разработанных бизнесс-процессов. И мое заявление "Вы тут все не так делаете" не прокатит. Есть реальная задача: контролировать остатки при изменении в документах при проведении задним числом.

В ходе обсуждения выяснено, что есть варианты:
1) Контролировать в проведении. Недостатки: блокировки и переписывание кода.
2) Контролировать перед записью в форме. Недостаток: остатки можно одновременно списать нескольким пользователям.

(47) Так двух зайцев нельзя убить одним патроном.

(48)+ Нужно выбрать меньшее, чем стОит пожертвовать.

(48) Ок. Будем их душить.

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

(0)при списании партий если их нет выдает ошибку, можно там попробывать поставить отмену проведения

(52) Расчет партий в регламент! :) При проведении не делать, мы договорились.

а вот как ... отследить что хочет сделать пользователь

например - есть док на приход 10 штук на 01/01/06
соответсвенно по этому товару есть и расход 10 штук 10/01/06

оператор находит ошибку - надо было оприхоовать не 10, а 20 шт

его действия ... меняет в ТЧ количество на 20
наши действия ?

действия системы
отмена проведения ! ()
запись изменений
Проведение

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

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

(55) При вводе строки дока можно проверять остатки, но могут быть тормоза...

Есть мысль:

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

Ваше мнение, господа!

(55) Резонно! Еще один большой минус варианту размещать проверку остатков в форме документа.

я думаю над такой заморочкой
прикрутить ко всему этому делу бизнес процессы

при отмене проведения дока (хоть прихода, хоть расхода)
отменять проведение всех документов по номенклатуре - и кидать их в задачи на проведение

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

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

(60) почему ?

(партии у нас списываются документами)

(57) Лучше правильно настроить последовательность документов
Если это не критично, то отказаться от движений партий по документам, проводить в конце месяца перед расчетом себестомости.

(63) Как правильно настроить?
Проблема в том, что в базе велика вероятность минусов. При восстановлениии последовательности партии не распределятся.

Возможные решения:
1) запретить минусы => тормоза и блокировки
2) ежедневно контролировать документы, из-за которых лезут минусы и исправлять ошибки

(64) Есть еще решение: подождать выхода 8.1 - если там тормозов и блокировок небудет, то вы можете спокойно проверять остатки в ОбработкеПроведения.

(65)
1) Интересно когда будет выход?
2) Для отсутствия блокировок код придется дописывать?

(66) Да, там есть управляемые блокировки. Выход-то намечают, но это приблизительно. Я думаю, что ноябрь-декабрь.

(67) Ну что.
Голосуем за контроль остатков в модуле проведения?

протифф

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

(68) Каждый сам для себя голосует. Я не знаю вашу фирму и ваши процессы. У меня есть фирма - контроль остатков в форме, а есть фирма - контроль остатков при проведении.

Сорри, может не в тему, но если так поставить вопрос - неправильно забитый документ дал неверный остаток. А что если взять да и провести Инвентаризацию? Она как раз и предназначена для исправления таких ситуаций?
Сильно не пинайте, работаю с бухгалтерией преимущественно 77.

У нас более 10 лет работает система (не 1с), в которой для изменения задним числом необходимо "отменить" все документы, связанные с партиями изменяемого документа. Причём, ручками (система подсказывает какие).
Если день назад - это ещё реально, два дня - никому и в голову не придёт распутывать этот клубок.
Если бы такая система была в 1с УТ (а это вполне реально и не сложно реализовать) - те, кто разрабатывал/утверждал бизнес-процесы вашего предприятия (47) вероятно изменили бы своё решение.

(73) о) у тебя система для пользователей или ползователи для системы?))

(73) No comments!
Если б я в своей компании к директору пришла и сказала - "воть, теперь у нас будет так!" - меня бы вышибли и денех не дали! :)

(75) технологии складского учёта разработали не ваши топ-менеджеры и даже не 1с, им несколько сотен (тысяч) лет. вы что, в амбарной книге будете подчищать записи и вырывать листы? Если вы (ваше руководство) согласны на это, то должны и фальшивые остатки/себестоимость кушать в соответствии с правилами ихнего "уникального" бизнеса или "конкурентного преимущества".
(74) - система для учёта, прежде всего; пользователи - материал переменный, правила учёта - постоянные. Не нужно по принципиальным вопросам идти на поводу у пользователей/заказчиков/руководителей. У вас, в конце концов, есть ит-директор, если нет - то сами доказывайте, что нехорошо вчерашний день корректировать. вы же потом и будете ночами/выходными перепроводками заниматься и минусы куда-нибудь пристраивать.
Разрешите творить гадости вашим пользователям в течении дня, потом препроводите этот день. Всё остальное - сторнированием. Уверяю, и вы и ваше начальство со временем с этим смирится - не враги же они своему бизнесу.
И не нужно изобретать ИТ-велосипеды в сфере учёта, всё уже давно изобретено.

(70)
"Остатки нужно контролировать, если есть изменения задним числом - факт. Другой вопрос что их нужно контролировать не только на момент времени, но и на текущую дату. Тут без перепроведения последовательностей не обойтись. А это уже великие тормоза ."

Бред. Есть методики без тормозов... Просто все методики "а ля 1С" - ориентированы на ГП и перепроведение. Так проще разработчику...

(73) Это пример решения проблемы. Не самый хороший, тормозной - но решения. Опять таки через перепроведение. Такое решение предусмотрено идеологией 8-ки... где можно отслеживать такое....


(65) Есть еще решение: подождать выхода 8.1 - если там тормозов и блокировок небудет, то вы можете спокойно проверять остатки в ОбработкеПроведения.


Бред сивого мерина в ясную лунную ночь


(76) Ты фантастические романы не пишешь?

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

Нормального решения в ветке никто не предложил
Только "в стиле 1С" - с трахом...

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

(77) Будь проще - и люди к тебе потянутся.... Не бизнес работает на ИТ, а ИТ работает на бизнес... И бизнес платит деньги... Если ты не можешь решить проблемы - бизнес не платит.
А заднее число возникает не только из-за ошибок - иногда оформление сделки задним числом дает возможность вполне законно сэкономить... А ты запрещаешь это оформление...
--------
Я не вендор, я работник/участник в этом самом бизнесе. Посему, у вас может быть другой взгляд на эти процессы.
Моё ит-подразделение работает совместно с бизнесом бок о бок. Собственно, я - тоже часть "топ-менеджеров".
Посему, вопрос стоит так:
вам (бизнесу) нужны реальные данные?
1. да - не допускайте решений, противоречащих идеологии информационной системы и здравого смысла.
2. нет, не важны/мы готовы терпеть “липовые” цифры - готовьтесь сводить месяц в течение следующего месяца.
При любом из этих вариантов основной бизнес несёт потери. Но потери в первом варианте можно свести к минимуму налаживанием нормальных бизнес - процессов, повышением квалификации пользователей.
Во втором потери неуправляемы и непредсказуемы.
1С УТ предлагает как раз этот выбор. А уж то, что вы выбираете – вопрос вашей корпоративной религии.
А вот выполнять любые пожелания руководства – это к хотабычу, а не ит-отделу.
Ps.: Конечно же, всё это только если ваш наниматель не относится к криминалу или около. Там свои правила. Но там совсем и не до учёта.

"У лю 427: P.S. изучайте другие системы, даже поганые - там есть изюминки..." - ну и дай наводку, чего из пустого в порожнее переливашь?

(79)
"Посему, вопрос стоит так:
вам (бизнесу) нужны реальные данные?
1. да - не допускайте решений, противоречащих идеологии информационной системы и здравого смысла.
2. нет, не важны/мы готовы терпеть “липовые” цифры - готовьтесь сводить месяц в течение следующего месяца.
При любом из этих вариантов основной бизнес несёт потери. Но потери в первом варианте можно свести к минимуму налаживанием нормальных бизнес - процессов, повышением квалификации пользователей.
Во втором потери неуправляемы и непредсказуемы."


"1.  да - не допускайте решений, противоречащих идеологии информационной системы и здравого смысла. "

Неверные акценты... Сначала должен быть здравый смысл, потом идеология информационной системы... Если идеология ИС ущербна - не надо натягивать бизнес на нее, ИС... Идеология 1С только частично соответствует здравому смыслу - она сделана ради наличия самой системы... и весьма оторвана от бизнеса. Хотя и есть определенное соответствие жизни...

  Если выкинуть ошибки юзеров, то заднее число все равно требуется - либо ради оптимизации налогов, либо для согласования дейсвий продавца/покупателя. Западные системы решают это через простое сторно и повторный ввод правильной инфы (плюсы - аудиторский след). 1С решает через перепроведение... Другие разработчики - решают другими методами...


"2. нет, не важны/мы готовы терпеть “липовые” цифры - готовьтесь сводить месяц в течение следующего месяца."

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

На самом деле есть третий путь -  можно весьма значительно ослабить жесткость за контролем действий пользователя (допустив определенное размиздяйство)  и СРАЗУ иметь корректные результаты...
  для этого нужно много думать. Чтобы создать дуракоустойчивую и размиздяйствоустойчивую ИС. Идеи такой ИС давно известны - хороших реализаций очень мало... Причины этого тоже известны...

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

P.S. кстати, идеология с перепроведением для восстановления ГП (и партионного учета) несет в себе свинью
- при вставке/правке дока задним числом не факт, что распределение по партиям пройдет успешно (и вообще возможно)
- поплывут партии.  Если рентабельность сделок считалась от себестоимости партий в наличии - можно пролететь...

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

(80) пошел в сад...
Тебе надо - либо ты ищешь сам, либо нанимаешь человека и он ищет...

Нахаляву - мы все мастера...

Вообще то это коммерческая информация и неслабо стоит...
Целые конторы неплохо живут на грамотных сравнительных обзорах...

(82) Жмот

Какие могут быть варианты решения:
1. Вести учет исключительно оперативно, не вносить документы в предыдущих датах. Если нужны какие либо корретировки, то вносить их тоже оперативно.
2. Если допустить внесения движений "задним числом", то тогда нужен пересчет (перепроведение) последующих движений. Если реализовать это "с умом", то можно минимизировать кол-во проведений и перепрведений. Операция восстановления последовательности можно осуществлять во время наименьшей загруженности системы.
3. Разрешить внесение данных неоперативно, но при записи движений проверять все последующие списания. Это самый затратый по производительности способ.
Например, собираемся списать с какой либо партии некое кол-во, проверям все списания от документа до текущей даты. Если залазим по этой партии в минус, то выбираем следующую партию для списания.
4. В случе партионного учета, то отказаться от партий и вести учет по средневзвешанной. Сбестоимость считать в конце месяца, по результатам дейятельности за месяц.

Что забыл?

(84) почему жмот? Если я потратил на изучение месяц, затратив время и деньги - почему ты это должен получить бесплатно?

(85) не совсем так...

"1. Вести учет исключительно оперативно, не вносить документы в предыдущих датах. Если нужны какие либо корретировки, то вносить их тоже оперативно. "

Нереально. Иногда ошибки всплывают через неделю - две..


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

Это подход 1С. При арифметическом прогрессии возрастании количества "задних" чисел геморой растет растет в геометрической. В некоторый момент геморой стопорит систему.. на восстановление ГП уходит больше времени и сил, чем на основную работу


"3. Разрешить внесение данных неоперативно, но при записи движений проверять все последующие списания. Это самый затратый по производительности способ.
Например, собираемся списать с какой либо партии некое кол-во, проверям все списания от документа до текущей даты. Если залазим по этой партии в минус, то выбираем следующую партию для списания."

Если сумеешь "просчитать" движения быстро - тогда метод полетит.
Работоспособный метод. Может применяться как для себестоимости, так и при некоторой модификации для учета по серийникам.


4. В случе партионного учета, то отказаться от партий и вести учет по средневзвешанной. Сбестоимость считать в конце месяца, по результатам дейятельности за месяц.


  точная себестоимость за месяц будет известна в конце месяца...
В течении месяца, если делать отчет от начала месяца до последнего дока за этот месяц - будет некая "текущая" средневзвешенная оперативно. Которая в условиях равномерной инфляции будет достаточно точной...

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

(86) >"Если я потратил на изучение месяц, затратив время и деньги - почему ты это должен получить бесплатно?"

Имхо это америкозная/еврейская философия.


Очень простой (буквально несколько строчек кода) контроль остатков делается через события (штатный механизм 7.7/8.0). Пример на 7.7
Книга знаний: Асинхронная работа с регистром остатков 1С: полезные алгоритмы

(+87) При этом массовое перепроведение не натыкается на ошибки, и никоим образом не замедляется.

все не читал, но правильней всего править не задним числом , а текущими документами ИМХО.

+(89)Соответственно с этим запрещать неоперативное проведение, а все исправления вносить текщим числом.

(90) эта методика известна, ее использует зарубежное ПО.
имеет достоинства и недостатки

P.S. но иногда "заднее" число - это не исправление, а новые документы...
Тут эта методика прокалывается...

(91)Да то главная проблема в этой методике :(

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

В семерке работа задним числом с расчетом остатков и контролем их на текущий момент делается как два пальца об асфальт. Тоже самое можно сделать и в восьмерке. Некер было тока систему раздувать.

оказывается v8 еще поганее чем v77, а франчи гады еще агитируют с 77 на 8 перейти. побольше денег хотят срубить. Вообще не надо было нам на 1С переходить работали бы без проблем на старой программе как раньше.. под ДОС.

(94) попал... в ЖПО пальцем...


(93) думать надо... и все получится...

(95) она не лучше и не хуже...
Она такая же - принципы те же...

Господа!
Если кому-нибудь интересно, мое решение для нашей системы.
Напоминаю: у нас документы расхода могут вводиться и исправляться вчерашним числом, потому что:
1) иногда первичка попадает не сразу просто из-за географической удаленности;
2) отчеты о продажах на посах вводятся утром следующего дня и в принципе могут делать отрицательные остатки;
3) пользователи косячат и никто из руководства уже не согласится на запрет исправления документов задним числом.

1) Решила не добавлять проверку остатков при проведении задним числом, чтобы избежать блокировок и переписывания типового кода;
2) По всем отрицательным остаткам, полученным в результате продаж на кассе на начало дня обработкой делается оприходование (все равно все минусы должны быть оприходованы по результатам ревизии). Такие оприходования естественно засчитываются в результатах ревизии;
3) Далее перед регламентированным расчетом себестоимости администратор будет запускать простенький отчетик, показывающий какие документы уходят в минус. Как правило, минусовой остаток является следствием неправильного времени документа. Т.е. Администратор базы запускает отчет, поправляет эти ошибки и запускает перепроведение и расчет себестоимости.

Плохое решение...

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

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

100   за ЛВП....

(98) По всем отрицательным остаткам, полученным в результате продаж на кассе на начало дня обработкой делается оприходование (все равно все минусы должны быть оприходованы по результатам ревизии). Такие оприходования естественно засчитываются в результатах ревизии;
<-----
А что указывается в качестве себестоимости в этих оприходованиях?
Средневзвешенная, последнее поступление?
И что это вообще даёт? Списание себестоимости вместо 0 идёт что-то более правдивое?
Минусов нет? А как на счёт плюсов?
Как вариант, вполне жизнеспособно.
Была похожая идея. При списаниях парий в минус автоматом приходовать на ордерный склад, а затем использовать типовые механизмы при работе по ордерной схеме. Это не спасает от перепроведений, но хоть более менее достоверные цифры по себестоимости.

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

(100) (101) (102)
Напоминаю, что при работе с УТ возникла проблема с расчетом себестоимости при отрицательных остатках.

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

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

СЛишком сложная схема.... Можно проще и ответ иметь сразу... Верный ответ...

(104) Извини, может я что-нибудь пропустила раньше...
Намекни как "можно проще и иметь сразу"... :)

Зачем намекать... Все равно не оплатишь...

Так что придумывайтее сами...

(106) ХАХА :)
Ну раз не можешь сказать, то и не пиши

Разрешаю трах самостоятельно...

Научное название самостоятельного способа приводить не буду....

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

а поспорить слабо?

(111) По-моему смысл форума в обмене опытом... Если не хочешь обсуждать тему и предлагать решение - вряд ли нужно писать.

(111) А спорить в форуме на фик не надо. Я в реале не обделена нормальным общением.

Тук-тук - громко гудел барабан на весь лес....

(109) ты ему даже научное название придумал?
А наука то об этом знает?
Возможно, неплохой учёный из-за жадности так и пропадёт.

(113) Я ужо про эту тайну беспроблемной работы задним числом давно слышу, думаю, что там такие грабли!!! Просто нам их не показывают.

(116) миздеть - не тележку мазать...

P.S. мне становится страшно - неужели одноЭсники так тупы, что не могут додуматься до решения?

(117) Ну почему? Может быть это решение в этой ветке в той или иной степени было озвучено. А вообще, в каждой фирме все по-своему и нужно затачивать алгоритм непосредственно под эту конкретную фирму.

(118) Согласна на все сто.

Сам недавно поднимал эту тему, вопрос решил так, дописал в обработке: ПроведениеДокумента, код: ПроводитьОперативно,
В итоге, если дата указана задним числом, она вводиться в накладную, но остатки сверяются, на текущий момент. Чем такой вариант не устраивает? Волки сыты, и овцы целы.

(120) Это не гарантирует, что документ не ушел в минус. И при расчете себестоимости она не распредилится.

ну это не дает ему уйти в минус, поскольку контроль то оперативный

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

(117) проверять начальный остаток + приход за месяц  - расход за месяц по товару перед проведением.

(124) Пробовала - слишком долго для модуля проведения, блокирующего регистры...

(124) За месяц??????

(124) перемещения есть? не прокатит

(127) прокатит, если под приходом и расходом считать движения со знаком "+" и "-" соответственно.
А за месяц необязательно. Достаточно проверять с текущего изменяемого документа до последнего документа, который делает расход (реализация или перемещение)

столько всего наговорили.. а воз и ныне там.)
впрочем, я тоже идеального решения не знаю..

(128) Наверное будет приемлимо работать на небольших базах. На нашей - слишком долго :(

(129) А лю знает! Но не говорит :)

(131) панты одни.

IMHO ковырять надо в сторону (73).
Можно эту схему доработать. Например, не всегда блокировать продажу партии задним числом, а только тогда, если это приведет к отрицательным остаткам.

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

Над вопросом организации такой структуры IMHO и стоит подумать.

Как вы на это смотрите? Предлагаю продолжить обсуждение, так как такое решение пригодилось бы всем.

(134) По-моему денормализации итак в 1С выше крыши. После реляционных баз данных к 1Су очень сложно привыкнуть...

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

(133) вопрос. для того чтобы узнать отрицательные остатки будут или нет тебе нужно произвести расчёт(по остаткам.)
получаем два посл. действия.(в типовых)
1.получение остатков.
2.перепроведение.

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

+136 сам узнал из рассылки:)

В УППхе сделано так:

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

Но проблему отрицательных остатков она не решает :-(

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

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

(139)О а вот это хорошая мысль, надо бы подобное сделать, только выдать как идею шефа, а то менеджеры и операторы меня прибьют ;) - главное ниодной строки кода менять ненадо :)))

я полностью согласен с pit`ом.
Считаю, что понятие "Граница последовательности" и следовательно "Позиция документа" -ЗЛО. ну невозможно автоматизировать людей с точностью не то что до секунды, а до позиции документа. в этом случае не программа работает на человека, а человек на программу, трахаясь сортировкой документов по последовательности.
автоматизировать так можно только машины.

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

Поэтому, я предлагаю отказаться от расчета итогов регистров на документ, а производить его на конец МЕСЯЦА документа (или дня, квартала (кому как нравится. можно включить выбор интервала дискретизации в настройках конфигурации на усмотрение вплоть от позиции до года:)).

в этом случае система совершенно не чувствительна к последовательности расположения документов в пределах интервала дискретизации. Главное, чтобы не было общих минусов за месяц, т.е. ,ОстатокНаНачалоМесяца+ВесьПриходЗаМесяц-ВесьРасходЗаМесяц >=0   тогда партии распределятся всегда, и итоги на конец месяца должны быть актуальными без перепроведения документов.

ЗЫ: при работе задним числом в текущем месяце итоги будут браться на ТА.

(132) панты в лесу... Называется лекарство - пантокрин...


(141) фигня-с.... идея... в чем то перекликается с (120)
С чужой конфой, построенной по идее (120,141), я работал еще в 2001 году... Врагу не пожелаешь... там классные грабельки есть...

(141) "Главное, чтобы не было общих минусов за месяц" ... не катит... Себестоимость не посчитается...

(138) Решение в УПП - это чисто технологическое решение для ускорения времени проведения - а сам принцип неизменный...


P.S. Одну маленькую мудрую мысль Пионерка высказала в (130) ... Офигительный прогресс за время обсуждения...


(134) решение УЖЕ есть...

(141) "Разделить все поровну" (с) Шариков П.П.

(142) "решение УЖЕ есть..." - решений куча, нужно выбрать подходящее
(143) "В топку!" (С) Ф.Ф. Преображенский

(139)
"на фирме после введения штрафа за выписку в "-" (а у меня такие ошибки чаще всего) количество минусов резко уменьшилось"


В ТиС 9.2 есть способ выписывать товар в минус, причем имея небольшие права, можно не только выписать в минус (даже если это и ЗАПРЕЩЕНО установками), но и положить этот минус на соседа...

(144) Полноценного решения, быстрого и безгеморойного, здесь нет...

(142) рещение (141) от (120) отличается тем, что контроль ведется на конец месяца ДОКУМЕНТА, а не на ТА. естественно, что при вводе документа задним числом раньше одного интервала дисретизации (месяц) надо проверить остатки на конец каждого последующего интервала до ТА, но зато не на каждый документ!
Грабли здесь могут быть только в виде "неопределенности" что было раньше: курица или яйцо. Любые грабли можно обойти. естественно что требуется дополнительная доработка.
и с херов-ли себестоимость не посчитается? все считается!

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

Грабли там будут при перепроведении, в зависимости от порядка проведения документов прихода и расхода...

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

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

(133) Кардинально увеличить скорость вряд ли получится. Поэтому если о чем и думать, так о том, как избавиться от возможных минусов когда эта проверка осуществляется в процедуре ПриЗаписи.
Я думаю о варианте со своими блокировками, которые будут действовать, начиная с процедуры ПриЗаписи и заканчивая ОбработкойПроведения (как вариант - справочник «Блокировки», подчиненный справочнику Номенклатура).
Этот вариант более реально осуществим нежели создание структуры, уменьшающей время  проведения. Кроме того, механизм неоперативного проведения менять ненужно - остатки не проверяются и проведение идет быстро (блокировка регистра минимальная). Самое большое время - в ПриЗаписи и оно блокирует только конкретные товары по конкретным измерениям (измерения - это реквизиты в справочнике «Блокировки»).

(136) Осуществление расчета не будет являться обязательным условием, если наложить определенные условия.

Попробую описать мои мысли. В качестве примера рассмотрим списание партий товаров.

Допустим, мы вводим такое ограничение: любое поступление товаров образует новую партию (даже при возвратах). Таким образом, остатки на ТА в разрезе партий показывают, сколько товаров из какой партии осталось.

Теперь посмотрим на операции задним числом:
Вариант 1: Увеличение количества товаров в партии (появление новой партии). Такую операцию можно сделать ВСЕГДА, так как она заведомо не сможет привести к отрицательным остаткам.
Вариант 2: Уменьшение количества товаров в партии (исчезновение партии). В случае уменьшения количества надо всего лишь проверить количество на ТА (заметьте, без дополнительных длительных расчетов). Если оно больше дельты, то такую операцию осуществлять можно. В случае исчезновения партии получаем частный случай (если товар из этой партии продавался, то НЕЛЬЗЯ).

В данном случае денормализацией является регистр партий товаров. Вообще-то, в 1С любой регистр - это и так денормализация структуры БД.

Надо еще подумать, но, ИМХО, в этом что-то есть ...
Может, какие-нибудь подводные камни я не вижу ?

+(150) Надо еще накладывать ограничения, какие - пока не понял

(138) Перепроведение с использованием таблицы значений.... Аллилуйя.
1С наконец-то додумался до этого. В семерке одному клиенту я сделала это 2 года назад. Потом продала эту обработку еще двоим...

(150)
Грабли:
1) если в одном документе прихода увеличил количество, в другом документе расхода можешь легитивно уменьшать количество. При твоем способе - это невозможно.
2) Это работает только для ФИФО

(152) самое интересное - это вообще не нужно....

А что если списывать с/с при закрытии периода? В течении месяца накапливать с/с по партиям. Списание товара проводить только по количеству без разреза пратий. А в конце месяца делать закрытие с/с по партиям.

(154) Если б я была модератором, засунула б тебя в игнор. От тебя все равно только громкие заявления, не подкрепляемые аргументами :)

(156) 500 баксов и будут тебе аргументы... И даже с примерами...

P.S. а насчет игнора - что, халявы так хочется?... нравится, когда даром, а ты деньги в кассе получаешь? мне тоже так нравится...


(155)
"А что если списывать с/с при закрытии периода?"

Так регламентное списание партий - это и делает по сути...
В том же самом обсираемом БЕСТе это появилось лет на 5 раньше УПП, причем сделано очень четко... и гораздо красивее, чем в УПП...
А до БЕСТа - еще много где было....

Если мы не получаем достоверную с/с до перепроведения всех документов, зачем мы тратим машинное время в момент проведения документов в течении месяца?

(156) у меня есть конфа дл восмерки в которой проблема изменений задним числом решена, но УТ ты так не переделаешь. Конфа опытная, просто для отработки концепта.

(158)

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

(160) согласен, щас найду свою статейку

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

Почему невозможно? В предложенной в (150) схеме основная мысль в том, что документы прихода не могут увеличивать количество в уже существующих партиях, а создают новые партии, поэтому при проведении можно опираться на остаток на ТА.

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

Если же допускать локальные отрицательные остатки, то тогда вообще можно отказаться от регистра, а хранить только состояние партий на ТА.

"Но, несомненный плюс в том, что этот расчет можно выполнить за пределами транзакции. "


Так делать нельзя... Обязательно влетишь в невероятное и провалишься в минуса...

Концепция оперативной бизнес логики.

Что есть. Типовые механизмы контроля.

В работе учетной системы часто возникает необходимость изменения документов задним числом. При этом в любой сетевой системе, эти изменения не исключения, а правило, т.к. при параллельной работе многих операторов информация, устаревает прямо пропорционально их количеству, к тому же часто внесение данных растянуто во времени.
Типичная проблема изменений задним числом, это необходимость контроля всех последующих связанных в системе фактов. Типовые механизмы проведения документов фиксируют учетные сведения на момент документа. Контроль логики осуществляется так же на момент документа. Когда изменения в базе происходят задним числом, такая реализация контроля фактически приводят к нарушению логики работы системы. Для корректировки ситуации в платформах v7&v8 предусмотрен механизм восстановления последовательности документов, подразумевающий последовательное перепроведение документов. При этом механизм работает только в монопольном режиме и для корректного завершения процедуры необходим оператор, исправляющий обнаруженные ошибки.  Для платформы v8 в текущих типовых конфигурациях для некоторых видов документов, продвигается решение этой проблемы на основе корректирующих документов вводимых текущим временем. Но партионный учет нормализуется все так же восстановлением последовательности.
По идеологии V8,  например контроль остатков товаров осуществляется только в момент оперативного проведения документа. При необходимости изменении задним числом базовый документ не правится, а на его основании вводится корректирующий документ, который, опять же проводится оперативно и осуществляет контроль действий пользователя. Подход верный в теоретическом случае, в итоге сильно увеличивает нагрузку на оператора, который не имеет связной текущей картины. Приходится отслеживать всю цепочку корректирующих действий, что в случае значительных объемов информации приводит к ошибкам и усложняет работу.

Таким образом, имеются следующие недостатки классической схемы:

·    Неадекватность работы логики системы.
·    Трудоемкость выявления фактов нарушения логики работы.
·    Необходимость выполнения ресурсоемких регламентных операций, часто на время операции работа с базой в рабочем режиме прекращается.
·    Ресурсоемкий контроль задним числом.
·    Отсутствие информации по изменениям, внесенным оператором.
   
Что может быть. Вариант конфигурации.

·    Полный оперативный контроль остатков, даже при изменении задним числом.
·    Полный оперативный контроль и порядок (в данной разработке логика FIFO) партионного списания, даже при изменении задним числом.
·    Изменения задним числом без необходимости восстановления последовательности.
·    Исключение при изменении задним числом ошибок логики перепроведения.
·    Контроль логики списания, без расчетов регистров задним числом.
·    Всегда фактический базовый документ.
·    Наличие «аудиторского следа».
·    Простота работы оператора.



Вводные ситуации:

А)ПН№1 -  приход товара 10.ПН№2 – приход товара 10.РН   – расход товара 15.ПН№3 – приход товара 10.
В случае если в ПН№1 или ПН№2  кол-во товара устанавливается равным меньше 5ти. При изменении считалось, что уменьшение кол-ва товара компенсируется ПН№3.  Тогда типовой механизм в момент восстановления последовательности остановиться на РН с сообщением о невозможности списать товар.  Придется вручную сдвигать РН на момент после ПН№3.

Б)ПН№1 -  приход товара 10.ПН№2 – приход товара 10.РН   – расход товара 15.РН как видим, списывает 2 партии 10 - ПН№1 и 5 - ПН№2.
Если мы увеличим кол-во товара в ПН№1 до 15ти, то логика партионного списания для типового варианта нарушается и возникает необходимость перепровести РН. Чтобы списалась только партия по ПН№1.

Предлагаемая схема.
В упрощенном виде работает следующим образом:

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

По случаю А. Вариант контроля остатков:

Для записи движений по остаткам используется отдельный документ – «КорректировкаЗаписейОстатковТовара», единый для всех документов участвующих в учете по остаткам ТМЦ.
Для записи актуальных движений используется регистр сведений.

1. ПН№1 уменьшаем кол-во до 3х.
2. В актуальном времени для ПН№1 делаются движения:
3. Сторно (-10)
   Приход (3)
Т.к. изменений документа может быть больше одного, для того чтобы сторнировать документ нам необходимо знать его последнее актуальное движение.
4. В необходимых разрезах (товар, склад) делаем контроль остатков.
Текущий остаток с учетом реализации в РН равен =  +13. Контроль пройден.
5. Записываем текущие актуальные движения. (старые удаляются)
При изменении РН задним числом, движения по ней будут осуществляться актуальным временем, и ошибки контроля остатков не будет.
Предупреждаю, что в предлагаемой конфигурации для случая остатков товара любое изменение в документе ведет за собой перезапись всей табл. части номенклатуры. Такой механизм может быть переработан, так чтобы изменения фиксировались только для тех товарных позиций, по которым действительно произошли изменения.

Для случая Б. Партионный учет по FIFO:

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

1. ПН№1 увеличивается кол-во товара до 15ти.
Для партий, осуществлено отслеживания измененной позиции и движения формируются только по ней.
2. ПН№1 выбирает актуальные движения (кроме самих партий) по измененной позиции.
РН - ПН№1 (– 10шт.)
РН - ПН№2 (– 5 шт.).
3. Все выбранные движения сторнируются.
РН – ПН№1 (+10шт.)
РН – ПН№2 (+5шт.)
4. Запросом по остаткам партий получаем актуальную картину.
ПН№1 – 15 шт.
ПН№2 – 10 шт.
5. Формируем движения для сторнированных документов.
РН – ПН№1, списано 15 штук.
6. Осуществляем контроль остатков.
7. Записываем регистр актуальных движения.  (старые удаляются)
РН – ПН№1, списано 15 штук.

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

Необходимая, но исключенная при разработке часть.

·    Механизм отмены проведения документов.
·    Удаление уже неактуальных движений.
·    Удаление в закрытом периоде данных по актуальным движениям. (свертка базы)
·    Восстановление значений актуальных движений (для изменений в закрытом периоде)

(163) Не провалюсь, т.к. при проведении идет контроль остатков на ТА.
Т.е., полученное распределение по партиям путем грязного чтения дополнительно контролируется при проведении, что и описано в (162)

(159) Если ты конечно не против, с удовольствием изучу твою конфу! У нас планируется написание своей конфы для оптового контура, окончательной концепции по этому вопросу пока нет...

(166) Заплатите и получите идею, на которой построите свою конфу...
У меня эта идея работает на 7 (бухкомпонента) с 01.01.2002

вообще говоря, там важны принципы, а не компонента....
есть вариант для регистров...

(166) мыло?

[email protected]

(168) Кинте и в меня, буду благодарен.

(167) Дорогой улю! Неужели, будучи хорошим программистом, ты до сих пор в нужде? Ведь в каждом втором сообщении просишь денег... Предлагаю открыть фонд помощи для сбора пожертвований :)

Меня не интересуют деньги как таковые... Интересна только одна их характеристика - количество...

А вот интересно списание заработаных средств уважаемый 427-й будет производить каким способом?

П.С. Не дай бог красненькое появится?!!!

(149) опять я ошибся. Вместо ПриЗаписи нужно читать ПередЗаписью.
А насчет отдельной тестировочной конфигурации с нуля - думаю с этого и надо начинать. Т.к. это быстро и сразу вживую видно все достоинства и недостатки конкретного метода. К тому же сразу можно протестировать и решить годится этот метод или нет.
Думаю свой метод набрасать, т.к. теоретически нельзя сразу увидеть ошибки, которые при эксплуатации в реальной базе могут быть критическими.

(171) Он неплохой орнитолог и разводила. Если бы идея была стоящей, то она бы сразу стала доступна многим.

(175) Да уж, ничего стоящего у него нет. Он сам в этом признался в (146)

(176) Да, в этой ветке нет стоящего решения...

(175) "Если бы идея была стоящей, то она бы сразу стала доступна многим."

С какого бугра? У каждого свои мозги, каждый мыслит по своему...
Я видел реализованными несколько вариантов этой идеи - люди додумались сами...
Просто я пошел чуть дальше и сделал идею немного более универсальной...

Странно другое - лежащую на поверхности идею не видят....
неужели ЖКК отбило большинство мыслительных аппаратов



P.S. Высказанных тобой стоящих идей я чего то не видел...
А я стоящие идеи не спешу опубликовать - идеи то не патентуются...
И после нескольких прецедентов (не буду описывать) и желания особого чего то нет... Публиковать бесплатно...
Хотя раньше и публиковал и бесплатно...

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

(178)он высказывается, ты читать не умеешь, очень интересно пишет.
и очень информативно.

(178) Не хочется выглядеть лохом на фоне других? Тогда у кого же будешь учиться думать? Хотя это лишнее - думать... лучше жрать чужую разводимую лапшу...


P.S. то, что здесь не заплатят и будут мучить клиентов неразумной реализацией - я знаю...

(1-179)
Может скинемся на концепцию? Он тут где-то 500 баксов просил...

(181) Незачем. Сам расскажет, если придумал что-то стоящее.
Гонор пересилит жадность ;-)

(182) ха-ха 2 раза...

Уж 2 года отправляю народ с ошибкой печати  на линию консультаций, хотя там всей правки - 7 символов...

Заинтриговал прям.. )) смена местами полож и отр движений даст изменение себестоимости на время последнего. оприходование по средневзвешенной обяжет к послед списанию что аналогично перепроведению.. а .. вообще прав - зациклились на ТА.. перепроведениях и последовательностях...

(184) точно заметил... зациклились...
Причем заметь - в обсираемом всеми БЭСТе задача решена без ГП...
Еще в паре систем - тоже без ГП сделано...

без контроля на бесконечную будущую дату не обойтись... чета близко но с/с смущает... завтра поищу ))  спас за подсказку

БЕСТовское решение влоб не применишь - слишком много переписывать...

(заинтересованно) а бесконечно будущая дата - это что такое?

(185) И пересчетов в БЭСТе не требовалось? У-ха-ха!

(188) что, неожиданная новость?
P.S. перепроведение требуется только в 1С...

(189) Ага, в других прогах это просто по-другому называется.

вот что пока есть по проведению задним числом
- ГП,  перепровдение доков
- док закрытие месяца,-  без перепроведния
- "ожидаемая" с/с - при уходе остатков в минус ставится тек с/с и флаг "ожидаемая". первый след приход сбрасывает флаг. - Проверка остатков по всем послед движениям партии. Вместо перепровдения работа с регистром остатков и себестоимости. Тут пока не ясно что делать в случае когда удалили какое-то поступление по партии (поменяли партию, удалили док :))) - его с/с можно вечно ждать )
Какие мысли?

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

(192) - да вариант. но не всегда и не у всех применимо...
4. сторнирование, - без препроведния )

по 4. Ахапта из-за этого кажется гораздо сложнее в использовании - где в 1с можно решить перепроведением за 5 мин в Ахапте нужно делать кучу доков.

(150) есть еще варианты - нужно отслеживать не только увеличение/уменьшение количества, но и изменение аналитики задним числом. Например, изменение склада, если, конечно, такое бывает. Хотя, если мы задумываем универсальный алгоритм - то всё должно отслеживаться.

Господа. Государствм  отпущено как минимум в бухгалтерском учете 3 месяца на все про все и баланс. :) Что и после трех месяцев тоже в зад лазить и менять суммы ?

5. Гибридный. Документ делает сколько угодно движений. Сторно прописывается на дату документа.
Вариант Joint
http://www.itland.ru/forum/lofiversion/index.php/t9695.html

(189) Согласен.
а лю 427, это бесполезно, IMHO.
Но рад, что в тебе все еще есть надежда.
.
(194) "1с можно решить перепроведением за 5 мин" ...и перепроводить, перепроводить.
Делать нужно не "кучу". :)
Гораздо сложне она только "кажется".
.
Рад, что 1Сников волнуют те же проблемы, что и 5-6 лет назад.
Удивляет, что решения тех лет снова являются для кого-то новостью настолько, что были предложения скинуться...
Немного напрягает то, что даже на такую смешную сумму в 500 баксов приходится скидываться.
.
Спасибо. Поностальгировал.

(198) не! именно кучу ) вручную сторнировать все что двигалось по партии после кривого дока... а это может быть не только отгрузка  - не у всех 1 склад и 1 магазин ;)
> Рад, что 1Сников волнуют те же проблемы, что и 5-6 лет назад.
Дык схема то не поменялась.. только 1С отказались от ТА и ввело магкое перепроведение без движения по регистрам...
Не увидел твоего устояшего ся мнения ) плз!

(198) пример! заведен в навижн приход с ошибочной валютой на 100 позиций. Через две недели заметили. за это время товар разбежался по магазинам на комиссию, продался, вернулся, вернулся поставщику... день работы на исправление.
В 1С - это поменять валюту и перепровести доки с этой партией... несопоставимо по временным затратам.

(199) читайте доки, они рулез.
Если вас интересует аксапта, готов пообсуждать на специализированных форумах.
.
здесь предлагаю сосредоточится на 1С.
И я о том же - схема не поменялась. ;)
.
"Мягкое перепроведение" только усугубило проблему ТА и ГП.
Готов послушать агрументы и буду рад ошибиться.

хех.."Тема не раскрыта"(С) не помню кто.

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

(201) Меня интересует 1С - а ахапта просто пример варианта сторнирования.
Мягкое перепроведение - неизбежно из-за тормозов при оперативном изменения. Забыли про него. Сейчас нас интересует рабочая схема изменений доков задним числом и контроль остатков, с/с при этом. Если есть рабочий вариант - скажите хотя бы "ЕСТЬ" как а лю 427, а не ностальнировать и отправлять к ртфм любой не в теме может

(204) Т.е. вариант с добавление к документу нескольких движений... я правильно понял?

Гм. А почему зациклились на себестоимости? Контроль остатков или его отсутствие влияют не только и не столько на себестоимость.
.
При неоперативном заполнении базы, да еще и проведении "авансом" без контроля оперативной себестоимости один фиг не получишь. И говорить, что здесь навар хорош, а здесь проиппали можно будет один фиг только после подбития итогов.
.
Оптимизация налогов за счет манипулирования себестоимостью требует предварительного анализа и планирования. И только потом манипуляций с товаром. И весь анализ с планом превратится в пшик после рывка на валютной бирже или скачка коммунальных платежей. А вот задним числом поманипулировать вполне реально. Только это тоже постфактум.
.
В свое время делал анализ реальной оперативной себестоимости подокументно в нескольких вариантах. Итог: оперативная себестоимость - фуфло. Все сводится к "по соеднему" при отсутствии колбасни в экономике. Да и чтоб прогореть колбасня должна быть строго определенного типа. Иначе эффект стирается на периоде квартал и более. А "подкорректировать" можно и потом.
.
За и против контроля остатков при неоперативном проведении есть куча обоснований. Но от разработчиков только один "аргумент": чтоб не тормозило.
.
В свое время решал проблему еще в 77. На решение натолкнул а лю 427 aka pit на т1с. Только сразу не въехал, пока звиздюлей не получил от босса. Решение проблемы контроля остатков лежит не в кодинге, не в методиках, а в организации ответа на простейший вопрос: что и в какой последовательности нужно добиться, т. е. в организации процесса. Тогда решение прямо перед носом.

эээ... тоже 500? или меньше? )

Анализ оперативной себестоимости после опробывания процесса на своей шкуре не менее 5000. Задача простая, но гемор...
.
Сам алгоритм... Ну ладно, подкину идеек. Только от идеи считать себестоимость "на лету" на время отключитесь, мозги засерает сильно.
- зачем неоперативно проводите, лично Вы? От тормозов или еще от чего? Что поиметь хотите?
- насколько важен партионный учет? Он нужен внутри или предписан законом (импорт, фармация, алкоголь,...)?
- как физически организован склад? Кладовщик в состоянии отличить одну партию от другой? Один товар в одной куче или раскидан? Сколько складских помещений, их территориальное расположение, коммуникации (свет, отопление)?
- уровень бардака в голове босса, его приоритеты?
- уровень "химии" менеджеров, откуда лезет заднее число, есть ли закрытие периода и каков период?
- оборачиваемость товара, разброс по позициям.
Вроде для начала хватит. Построив логически непротиворечивую цепочку действий произойдет просветление первого уровня: а оно нам надо? А потом, раскидав узкие места по цепочке просветлитесь до второго уровня: где ковырять надо. Ну и третий уровень уже рядом.
.
С а лю 427 не согласен в одном: универсального решения нет. Грабли есть всегда. И называются они юзер.

(208) Если не нужны партии и себестоимость "на лету", то вопрос решен. Только вот нужна она, себестоимость эта.

+(209) Тупо считаешь остаток при проведении и распроведении каждого дока и все. Но кроме количества ты на ничего не увидишь.

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

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

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

(213) Потому и говорю, что ПиТ в общем случае нагло гонит.

+(214) И по средней то не прокатит, ибо средняя после правки задним числом тоже поплывет.

Резюме: Грабли просто переносят в сарай и говорят, что их НЕТ. В сарай заходить нельзя. Пока Вам туда не нужно, вы восхищаетесь мудростью творца метода.

(206)
"Решение проблемы контроля остатков лежит не в кодинге, не в методиках, а в организации ответа на простейший вопрос: что и в какой последовательности нужно добиться, т. е. в организации процесса."

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


(208) "не согласен в одном: универсального решения нет. Грабли есть всегда. И называются они юзер."

Если просчитать все действия юзера - тогда решение будет универсальным...
P.S. за время после споров на т1с я пошел дальше...


(216) Бесполезно спорить со СлепоГлухоНемыми Дятлами...
Если ты не можешь сделать сам - не считай всех тупее себя...

(215) Если среднюю считать в конце отчетного периода, то "не поплывет"

вот так - грили грили и все разошлись на своем )