23.07.2003, 10:11 | #1 |
Участник
|
Создание заказав и количество товара на складе
Navision Attain 3.60.02
В Товары->Настройка->Товары Настройка на закладке Склад есть галочка "Разрешить отрицательный остаток". ее установка позволяет отрицательный остаток на складе. Суть вопроса в противоположном не только запретить отрицательный остаток на складе (это можно сделать простым снятием галочки), но и запретить даже создавать заказы которые превышают количество товара на складе. Таково требование заказчика, они не принимают заказы на товары, которые отсутствуют на складе, или которых недостаточное количество. |
|
23.07.2003, 10:27 | #2 |
NavAx
|
Как сделать это в настройках - не знаю, но это не слишком сложно сделать программированием (я знаком только с версией 3.01, не знаю, что в 3.60). В таблице Item есть такое вычисляемое поле - Qty. on Sales Order. Соответственно, можно на создании товара повесить проверку, которая не будет позволять создавать заказ в случае, если общее кол-во товара на складе (Inventory в той же таблице Item) минус кол-во товара в заказах (Qty. on Sales Order) меньше нуля. (по мере надобности можно также отнять всяческие Reserved Qty. on Sales Orders, Trans. Ord. Shipment (Qty.) etc).
|
|
23.07.2003, 10:33 | #3 |
Участник
|
Да повесить проверку можно проще простого. В этом я полностью согласен. Но к сожалению у нас нет доступа к CodeUnit'ам.
|
|
23.07.2003, 10:33 | #4 |
Участник
|
Насколько я знаю в стандарте это не предусмотрено. Предполагается, что заказ можно создать заблаговременно.
Проблему можно решить установкой проверки в таблице 37 Sales Line на тригер OnValidate поля 15 Quantity. Тут надо помнить след. вещи: 1. Эта табличка используется так же и для Кредит Нот - проверять тип документа. 2. Пользователь может скопировать строки из другого элемента - вставить проверку на копирование (хотя, если пользователь использует для копирования буфер обмена Windows - imho бесполезно). 3. Пользователь может изменить единицу измерения - проверять 5415 Quantity (Base). 4. Заказ создается из общего заказа - и туда проверку. 5. Что-нибудь еще вылезет В общем, возможно проще убедить заказчика пересмотреть свое представление об "эффективном" управлении логистическими процессами (это надо будет делать очень часто). Пусть привыкает мыслить новыми категориями. |
|
23.07.2003, 10:45 | #5 |
Участник
|
OFF:
Не надо зацикливаться на доступе к codeunit. Необходимость в их изменении возникает очень и очень редко. Большинство необходимых изменений вполне можно сделать в таблицах. |
|
23.07.2003, 11:52 | #6 |
NavAx
|
Зачем же сразу кодъюниты трогать. В крайнем случае можно вообще повесить проверку на триггер OnPush кнопки "Учет" формы 42.
|
|
23.07.2003, 12:26 | #7 |
Участник
|
Все дело в том, что мы можем писать код только для Отчетов и ДатаПортов. т.е. повесить обработку каких-либо событий на форму мы не можем.
Саму проблему наверное придется решить тем, чтобы убедить заказчика от идеи несоздания заказов. Особенность нашего внедрения в том, что мы внедряем Attain в одном холдинге. Он состоит из ряда (поярдка 30) компаний, каждая их которых имеет свой вид деятельности (розничная торговля, оптовая торговля, производство, строительство и наша компания, которая занимается информационными технологиями). Внутри этого холдинга существуют определенные взаимоотношения, которые определяют требования заказчика. Эти требования в силу сложившихся отношений могут показаться странными, но, в принципе, они имеют свою логику. Компания, которая требует, не оформления заказов в случае недостачи товаров на складе занимается тем, что закупает и перепродает товар другим фирмам холдинга. |
|
23.07.2003, 13:25 | #8 |
Участник
|
Как показывает опыт, внедрение системы на крупных предприятиях вынуждает производить отнюдь не косметические изменения. Рано или позно (а скорее всего уже сейчас) встанет вопрос о приобретении лицензии разработчика.
|
|
23.07.2003, 14:45 | #9 |
Участник
|
To Rungart:
Насчет разработки. Писать на C/Al, я думаю, найдется мало желающих и стоит он около 8000$, кажется. А MS VS .Net около 2000$. Хотя по удобству и возможностям намного превосходит C/Al. Мы планируем на следующем этапе писать именно внешние приложения на C#, используя при этом технологии ADO.Net и c/front ( СУБД у нас SQL Server). Зачем человеку, в обязанности которого входит, скажем, просто выписка счета выделять собственное рабочее место, число которых ограничено лицензией? Лучше написать внешнее приложение, которое будет обеспечивать ему необходимую функциональность. Именно для таких простых случаев мы собираемся использовать внешние приложения, в которых можно решить все эти проблемы более просто. А также для других операций с БД. Ну а сейчас мы пока удовлетворяемся Query Analyzer и возможностями ДатаПортов.
Как насчет такого подхода |
|
23.07.2003, 15:28 | #10 |
Участник
|
Интересный подход.
Было бы интересно взглянуть на более-менее работающий проект такого типа. Кстати при подключении по ADO к SQL контролируется ли число активных сессий, доступных по лицензии (насколько я знаю, если подключаться по ODBC к Navision Server, ограничение по лицензии работает). |
|
23.07.2003, 15:47 | #11 |
Участник
|
А-а. Вот в том то и дело, что при подключении по ADO к SQL Server или посредством интерфейса c/front (см. "C/Front Reference Guide", "Интеграция с Navision", установка: satrtcd.exe->Интерфейсы) количество активных пользователей не контролируется. А насчет работающих проектов такого типа. Есть у нашего начальника такой опыт, правда не с Attain, а с Галактикой. Но там дело обстояло гораздо хуже, чем с Navision структура БД намного сложней и глючней. Ну скоро, я думаю, будет опыт и с Navision.
Ведь такие идеи не из пальца высасываются. |
|
23.07.2003, 15:57 | #12 |
Участник
|
Что-то где-то я пропустил
"Средства интеграции Navision" : RURU_Navision 360_INT.pdf , стр. 3-16 : " ... В контексте ограничений основное недоразумение состоит в том, что многие считают, будто C/FRONT можно использовать вместо множественных сеансов. Однако, это не так. Каждое соединение в C/FRONT трактуется как сеанс. ..." Интересно, это баг или фича? |
|
23.07.2003, 16:10 | #13 |
Участник
|
Это верно. Но есть план обходить это дело путем написания Web-приложения, которое загружается на серваке и умирает. Таким образом мы экономим лицензии. Если конечно всех пользователей не попрет одновременно запустить наше приложение, но это маловероятно. Таким образом, достигается нечто вроде псевдомногопользвательского режима (но эта фраза не передает точно всей сути вопроса, но у меня нет слов).
|
|
23.07.2003, 16:18 | #14 |
Участник
|
Т.е. на сервере стоит "прокладка", которая берет данные из Navision и расшаривает их среди пользователей и обратно. Идея ясна. Удачи в ее реализации.
|
|