Интересует конструкция
If (Rlock())
...........
Unlock
endif.
1. Кто-нибудь ею пользуется?
2. Если да, то какой смысл ставить If, если "отката" не происходит при Rlock()==.F.?
Т.е. кто-либо, вообще, учитывает случай Rlock()==.F. и как? Просто некоторые операции нельзя как-бы откатить частично.
Или это решается на более "высоком" уровне путём различных семафоров....
Я использую просто RECLOCK()
А сам цикл блокировки доверяю механизмам БЭСТа.
Как в БЭСТе идет обработка - так и у меня.
Все внутри функции RECLOCK() разработчиком уже организовано.
Если самому делать то тогда
WHILE !RLOCK()
ENDDO
И дальше уже самому думать как его обрабатывать.
nordk пишет:
Саак я мягко говоря не правильно написал.
Я использую просто RECLOCK()
А сам цикл блокировки доверяю механизмам БЭСТа.
Как в БЭСТе идет обработка - так и у меня.
Все внутри функции RECLOCK() разработчиком уже организовано.
Если самому делать то тогда
WHILE !RLOCK()
ENDDO
И дальше уже самому думать как его обрабатывать.
Т.е. я так понимаю "патовые" ситуации в этом самом RECLOCK() и предусмотрены??? Верно???
Т.е. в случае, если там внутри "зациклит", то Бэст сам же этого "дотумкается"??? И что при этом произойдёт, вот что меня интересует. Просто вернётся .F. и ничего интереснее? Или прервётся(заморозиться) поток, в котором выполнялась данная команда?
P.S. Как, иногда, все-таки приятно узнать, что всё, что ты делал до этого, всё делал неправильно:)
А вот по поводу обработки конструкции
Код
WHILE !RLOCK()
ENDDO
нет правильных/нормальных инструментов, должен я Вам сказать... Так что как ни думай, а правильно самому её не обработать:) Поэтому так и интересуюсь данным вопросом.
nordk пишет:
Примерное описание RECLOCK() как это было сделано в БЭСТ-4 можно посмотреть на старом форуме
Я Вас увёл немного в другую сторону. Давайте вернёмся к обсуждению задачи, которую я уже начал потихонечку реализовывать.
Я тут задумался вот над чем. Сделать всё то, о чем мы говорили действительно несложно (всё это уже делалалось). Но вот что меня волнует:
Цитата
nordk пишет:
Через авторизацию самое правильное на мой взггляд.
Есть штатное средство, позволяющее не обвешивать систему плагинами.
Настройте роль и пользуйтесь ею
(это Вы говорили о запрете ввода и редактирования документов в штатном режиме)
Я только сейчас задумался над тем, а где, собственно, будут новые средства ввода/редактирования/удаления/распечатки документов приходования???
Из какого меню Б-5 эти действия будут осуществлятся!!!? Не из штатного же, которое мы договорились запретить (просмотр будет, естественно открыт, но ради распечатки туда лезть никто не станет.)
Вы улавливаете мысль???
Сделать несколько отдельных меню. В дереве меню Б-5 сделать папку "Отгрузка товаров". Внутри три меню:
1. Готовая продукция. В этом меню выводить списком продукцию, которая оприходована из производства. И при входе в данное меню сначала запросить заказчика и выводить список продукции для каждого заказчика. Естесственно тут будет ТОЛЬКО та продукция, которая присутствует в заказах. По этой причине должна быть опция "отобразить продукцию не из заказов" (Такого сейчас теоритически быть не может, но планировалось дать возможность заказывать продукцию на склад).
Как тут работать:
а) Отметили нужные позиции и нажали кнопочку - отгрузить. Далее начинает формироваться объект (складской объект).
б) Далее 2 варианта (тут тоже нужен совет): либо происходит автораспечатка накладной и сохранение. Либо открывается документ на редактирование, и пользователь сам решает сохранять ему док-т или распечатывать и т.п...
2. Отгруженные товары. А вот здесь как раз и сделать список этих самых документов (накладные отгрузки). Т.е. сделать "стандартный" реестр документов
отгрузки. Для того, чтобы дать пользователю возможность удалять/редактировать/ печатать (уже повторно), а также создавать: т.е. сделать вызов пункта 1 еще и отсюда. + добавить возможность отгрузки по нескольким заказам (а не по строкам заказов как в пункте 1.).
P.S.
Цитата
nordk пишет:
Если Вы делаете свой плагин, то Вы делаете свой пункт меню.
Его можно сделать где угодно
Должен сказать затея не так проста как Вам показалась на первый взгляд:)))
Небольшие трудности возникают при партионном учёте. И при условии, что продукция приходуется/отгруж может частями.
Кроме всего прочего придется запретить Оприходование ГП-товар!!!!
Т.к. удаление этих документов также неприемлимо!!!!
=> Придётся еще и делать новый механизм удаления этих документов...
Сейчас пока что размышляю над тем как лучше всего учитывать партионность и "частичность" движения...
Приведу код. Это моя таблица. Возможно, что-нибудеь лишнее подскажете убрать...
С индексами тоже все никак не определюсь.
Статус, думается также переделать надо. Добавить промежуточные состояния - "частично изготовлен", "частично отгружен"...
Еще надо сделать 3 поля в таблице - Кол-во изгот, кол-во отгруж. И memo поле для хранения кодов партий изготовленных изделий... НО я пока что неуверен нужны ли эти новые поля.
Саак Шахламджян пишет:
Статус, думается также переделать надо. Добавить промежуточные состояния - "частично изготовлен", "частично отгружен"...
Еще надо сделать 3 поля в таблице - Кол-во изгот, кол-во отгруж. И memo поле для хранения кодов партий изготовленных изделий... НО я пока что неуверен нужны ли эти новые поля.
непонятно если честно.
Если можно частично отгрузить, значит надо делать несколько партий - один заказ.
Саак Шахламджян пишет:
Цитата
nordk пишет:
Цитата Саак Шахламджян пишет:
=> Придётся еще и делать новый механизм удаления этих документов...
Такой метод у накладной имеется
Вы имеете ввиду метод у класса складских документов, верно???
Я, кажется такого не наблюдал! Поделитесь, пожалуйста!
Точно также создаете массив документов, только вместо RUN
Саак Шахламджян пишет:
Цитата
nordk пишет:
непонятно если честно.
Если можно частично отгрузить, значит надо делать несколько партий - один заказ.
Мне самому не очень-то понятно...
с тем как быть с этими партиями?
1. Также как и в картотеке складского учета на каждую новую партию заводить новую запись в моей таблице?
2. Или сделать memo-поле, в котром просто список этих партий, чтобы много мусора не было.
3. Вообще не следить за партиями, а сделать 2 новых поля:
Колич отгруж и колич изготовленных, а потом по надобности искать\подбирать партии.
Если предполагается несколько партий по заказу, то мне лично
напрашивается вторая табличка:
заказ и ROWID партии + кол-во
И в каждой партии поле с номером заказа.
Тогда по номеру я отслеживаю можно ли эту партию отгружать
конкретному партнеру и если да - то отмечать у себя.
Общее кол-во совпало с количеством заказа - закрываем....
Может будут мысли лучше - но я бы делал как-то так...
nordk пишет:
Если предполагается несколько партий по заказу, то мне личнонапрашивается вторая табличка:заказ и ROWID партии + кол-воИ в каждой партии поле с номером заказа.Тогда по номеру я отслеживаю можно ли эту партию отгружатьконкретному партнеру и если да - то отмечать у себя.Общее кол-во совпало с количеством заказа - закрываем....Может будут мысли лучше - но я бы делал как-то так...
Это будет немного слишком!!!
1. Кроме того не совсем состыковывается со сказанным ранее, а именно:
Если еще и партию каждую отслеживать, тогда придется все-таки закрыть абсолютно все виды движений, а => реализовывать их самому, а мы договаривались закрыть лишь те, которые уменьшают остаток продукта.
2. Делать еще одну таблицу ради такого тоже кажется не целесообразным.
В общем ввел 2 поля : колич изготовленных и колич отгруж.
А отгружать думаю, все-таки кавыряя картотеку. Заодно сверяя и остаток.
nordk пишет:
Думаю Вы меня не поняли
Я к первой таблице предложил добавить детализацию.
1. а) ROWID партии и номер заказа Вы предложили в другую таблицу(допустим, PartInfo.dbf) поместить верно???
б) ROWID партии - идентификатор записи из спр партий или mkart.dbf? Если да:
в) Придется "закрыть" доступ на другие движения, иначе они приведут к тому, что информация в таблице PartInfo.dbf будет недостоверна???
2.Честно говоря больше волнует распечатка накладных. За реализацию отгрузки особо не переживаю. Больше волнует распечатка документов и то, что еще придётся переделывать реестры стандартных документов.
По повду последнего сейчас задумался. Удаление я так понимаю будет реализовано стд методом (Вы его уже дали). А вот создание и редактир есть такие? И как они работают?
Саак Шахламджян пишет:
а) ROWID партии и номер заказа Вы предложили в другую таблицу(допустим, PartInfo.dbf) поместить верно???
б) ROWID партии - идентификатор записи из спр партий или mkart.dbf? Если да:
в) Придется "закрыть" доступ на другие движения, иначе они приведут к тому, что информация в таблице PartInfo.dbf будет недостоверна???
Не понипмаю зачем доступ закрывать ?
Заказ допустим на 10 штук
Мы выпустили продукцию 4 штуки.
Номер заказа разместили внутри карточки партии
Потом выпустили еще 6 штук к заказу.
В новую партию положили еще 6 штук.
Все.
Как и раньше контролируем отгрузку заказа.
Он состоит из 2 партий.
Все движения как были так и будут.
ROWID у карточки партии не меняется
При записи отгрузки контролируем те ли партии отгружаются и закрывается ли весь заказ или частично.
Что тут нового против разговора раньше ?
Создание есть - это собственно известный Вам метод.
Редактирования пока нет.
Я пока в своих задачах делаю удаление и создание нового.
Если удалить нельзя по причине красных остатков (это в случае прихода), то обрабатываю ситуацию.
Что касается печати - это мы решаем таким образом.
СОздали документ через объект - создание происходит с открытием документа на экран. В нем печать и все что надо работает.
После сохранения - печать только в типовом реестре.
На просмотр то он открыт.
nordk пишет:
Не понипмаю зачем доступ закрывать ?
Заказ допустим на 10 штук
Мы выпустили продукцию 4 штуки.
Номер заказа разместили внутри карточки партии
Потом выпустили еще 6 штук к заказу.
В новую партию положили еще 6 штук.
Все.
Как и раньше контролируем отгрузку заказа.
Он состоит из 2 партий.
Все движения как были так и будут.
ROWID у карточки партии не меняется
При записи отгрузки контролируем те ли партии отгружаются и закрывается ли весь заказ или частично.
Что тут нового против разговора раньше ?
Да в том-то и проблема, что ROWID у карточки партии меняется!!!
(Точнее сказать сама партия меняется, текущее кол-во. "Перетекает" из одной партии в другую => как бы меняется ROWID)
Цитата
Заказ допустим на 10 штук
Мы выпустили продукцию 4 штуки.
Номер заказа разместили внутри карточки партии
Допустим так. А потом кто-то взял и переместил эту партию на др склад. Или списал... Что тогда будет? Партия пропадет ведь, да? И получается, что ROWID партии, который мы с Вами храним уже не актуален. Т.к. наша продукция висит на др партии с др. RowID или вообще отсутствует (смотря что проиошло).
Или я что-то не так понимаю?
P.S. В общем черно-черно черновой вариант у меня сегодня уже реализовал продукцию со склада. Сделал просто поиск всех партий по гр. и Н\Н в определнном складе. Не могу сказать, что долго работает. (Хотя все на лок машине работае, по сети немного ниже будет скорость.)
nordk пишет:
Что касается печати - это мы решаем таким образом.СОздали документ через объект - создание происходит с открытием документа на экран. В нем печать и все что надо работает.После сохранения - печать только в типовом реестре.На просмотр то он открыт.
Я, к стати, по этому поводу в моём сообщении №59 так и спрашивал:
Цитата
...Либо открывается документ на редактирование, и пользователь сам решает сохранять ему док-т или распечатывать и т.п...
Т.е. получается перед непосредственным сохранением он-таки должен показаться пользователю!???
P.S. Вариант с oDocs:Hidden := 1 уже опробовал. Всё просто здорово!!! Очень порадовало!!!
Как всегда одно небольшое "Но":
Рег. номер у меня формируется стд WDOC функ-ей. Единственное, она иногда "даёт сбой". Если такая сит возникнет пользователи меня съедят, знаю точно. Бывает, что рег. номер выдается не самый большой, идущий след по списку, а, скажем № 000010. => После этого будет 11й и т.д. В случае со стд. реестром документов есть возможность посмотреть последний номер и ручками поправить его. В нашем случае такой возможности почти нет.
Нельзя ли в открытый документ повесить событие "перед сохранением" как это можно сделать в стд реестре документов??? Чтобы самому с этим номером "разобраться".