Просмотр полной версии : ТиС "Медикаменты" Структура регистров.
Кто делал типовое заданиеТиС "Медикаменты"
Вот часть задания:
Необходимо разработать конфигурацию, которая позволяет вести серийный учет медикаментов в аптеке, приходуя товар в отделы документами “ПрихНакл” и проводя продажи документом “Чеки”:
- Справочник “Медикаменты” с дополнительным периодическим реквизитом “РозничнаяЦена”, значение которого должно изменяться только документами;
- Справочник “Серии”, подчиненный справочнику “Медикаменты”, имеет дополнительный реквизит “ПредельнаяДатаРеализации”. В форме списка справочника “Серии” этот реквизит должен присутствовать и при просмотре записи справочника должны быть отсортированы по нему;
- справочник “Отделы”;
- Документ “ПриходнаяНакладная”, который приходует медикаменты от поставщика в один из отделов аптеки, рассчитывает и запоминает новые розничные цены;
- Документ “Чеки”, который служит для отражения в системе учета факта продажи медикаментов и списывает из отдела аптеки конкретные серии медикаментов.
Партионный и многовалютный учет не ведется, НДС и другие виды налогов в документах не указываются и не рассчитываются.
Структура регистра остатков “ОстаткиСерий” должна обеспечивать ведение количественного и стоимостного учета (по себестоимости) серий медикаментов в разрезе отделов, а оборотного регистра “Продажи” – количества и стоимости проданных медикаментов в розничных ценах.
------------------------------------------------
Как должны быть представлены регистры, у меня ничего не выходит :(
ОстаткиСерий
Измерения: Отдел, Серия, Себестоимость
Ресурсы: Количество
Продажи
Измерения: Отдел, Серия, РозничнаяЦена
Ресурсы: Количество
Так?
Получается что Себестоимость сохраняется только в регистре, я не могу ее оттуда достать, как обратиться к измерению? Себестоимость ресурсом делала, но по ответу преподавателя поняла что оно должно быть измерением.
На первый взгляд, я бы делал так:
Регистр ОСТАТКИ_СЕРИЙ:
Измерения: Отдел, Медикаменты, Серия
Ресурсы:Количество, Себестиомость
Реквизиты:ПрихЦена, РасхЦена
Регистр ПРОДАЖИ:
Измерения: Отдел, Медикаменты, Серия
Ресурсы:Количество, Профит
Реквизиты:ПрихЦена, СебестоимостьЕдиницы, РознЦена, РасхЦена
Ты можешь резонно заявить: зачем измерение "медикаменты" - ведь к ниму можно обращатья, как Серия.Владелец()? Но поверь мне, если сейчас на вставишь это измерение, то вдальнейшем замахаешься с отчетами.
Уже сделала, так как написала, но с отчетами мучений было....
Насколько я поняла, из рекомендаций при сдаче на 1С профессионал (а это задание именно оттуда), то за отступление от структуры, которая описана в задании снижают бал. То есть если туда добавить Медикаменты, ПрихЦена и РасхЦена это уже будет минус, видимо за засорение баз ненужной информацией.
Небольшое философское отступление... "Размер базы" и "Скорость работы" - суть антогонистические критерии, т.е. добиваясь положительного изменения одного параметра - почти всегда ухудшаешь второй. Имея за плечами некоторый опыт внедрений, я обычно "засоряю" регистры "ненужными" данными, за счет чего значительно увеличиваю скорость работы многих самых популярных отчетов, хотя и раздуваю при этом размер базы, чего и Вам желаю.
И еще. Экзамен 1С и ЖИЗНЬ - эт две большие разницы.
А вообще вопрос инетересный. Тут нужно на практике проверять, по-другому не выяснишь как лучше.
Насколько я поняла "размер базы" и "скорость работы" как раз почти синонимы. Это в большинстве случаев, может где-то, для какой-то конкретной задачи и наоборот.
Mulder_1
12.07.2005, 18:16
Уже сделала, так как написала, но с отчетами мучений было....
Насколько я поняла, из рекомендаций при сдаче на 1С профессионал (а это задание именно оттуда), то за отступление от структуры, которая описана в задании снижают бал. То есть если туда добавить Медикаменты, ПрихЦена и РасхЦена это уже будет минус, видимо за засорение баз ненужной информацией.
отступление:
дык вроде на 1С Проффесионал тесты здаются ... а такие задание идут на сертификацию по какой-то компоненте ...
отступление:
дык вроде на 1С Проффесионал тесты здаются ... а такие задание идут на сертификацию по какой-то компоненте ...
Возможно. Я не вникала, тогда это называется 1с-специалист, если не ошибаюсь.
И опять я остался непонят...
Аллочка!!! Конечно "маленькая" база будет работать "быстрее", чем "большая". Речь о другом. Как проектировать базу? Так, чтобы она быстрее росла, или быстрее работала (в смысле построения отчетов). Другими словами: или через год работы база будет весить 1ГБ, но в ней уже будут подготовлены данные для самых популярных отчетов, за счет чего они, т.е. отчеты, будут работать быстрее, или ВТОРОЙ вариант - четез год работы база будет весить 100МВ, но отчеты кроме функции "собрать информацию и распечатать", буду еще что-то вычислять, что, естественно, скажется на скорости их работы.
Именно в этом смылсе я противопоставлю критерии "Размер" и "Скорость" базы.
А не окажится ли так, что собрать готовую информацию по большой базе будет медленее чем ее рассчитать из маленькой?
Плюс еще на проведение документов будет требоваться больше времени. А если вдруг понадобиться сразу скопом перепровести большое количество документов?
Нет. Собрать готовую информацию из "большой" базы, как правило, получается намного быстрее, чем расчитывать эту информацию в "маленькой". Хотя, конечно, вопрос "Что собирать?" и "Что считать?".
А насчет того, что доки будут дольше проводиться - это ты в точку. Собсно, об том и разговор. Или доки быстрее буду проводиться, или отчеты быстее форомироваться.
"Сразу провести большое кол-во доккументов" желательно оформить, как регламентную процедуру, типа "восстановление ГП" и запускать автоматически ночью.
torch, интересній сайт http://torch.com.ua
Жаль только статьи не работают. :( Когда будет?
Mulder_1
14.07.2005, 12:06
имхо, низзя говорить что лучше большая база , или маленькая, сильно раздувать структуру то-же не стоит ...
должно быть оптимальное соотношение между размером базы и функциональностью...
не будете же вы ставить Производство на 8-ке для бухгалтера частного предпринимателя...
и кстати (опять же таки чисто моё имхо) долгое проведение документов - не есть хороший показатель....
з.ы. ксати torch со странным каким-то клиентом ты меня свел ..)
to (Mulder). Когда я слышу фразу "оптимальное соотношение", то вспоминаю мои походы с женой по магазинам, когда она пытала продавцов своей каронной фразой "а покажите мне туфли с оптимальным соотношением цена-качество". Я, конечно, пытался объяснить ей, что туфли надо выбирать по принципу нравится-не нравится... но потом мы шли выбирать хлеб, соль и спички...
Еще пофилософствую, с Вашего позволения. Для определения "оптимального соотношения" между размером базы и функциональностью нам нужно вывести некоторый числовой универсальный показатель, по которому мы смогли бы сравнивать разные базы. Например, таким показателем могло бы стать "суммарное время человеко-часов простоя по вине задумчивости компьтера в неделю". Но тогда вопрос "одинаково ли ценен для предприятия один человеко-час простоя тупой блондинки-оператора и ген. директора?". Очевидно, что нет. Значит, для получения универсального числового показателя качества системы мы должны определить, как по стоимости соотносятся человеко-часы простоя разных сотрудников. Короче задача приобретает явно спекулятивный (т.е. умозрительный) характер и уплывает из сферы точных расчетов в сферу наших СУБЪЕКТИВНЫХ представлений о жизни и бизнесе.
to (Mulder) об странных клиентах. Извини, коли че не так. Видимо наши представления об оптимальном соотношении параметров "жирный клиент" и "нестранный клиент" несовпадают. Это была шутка. Кстати, у меня остались некоторые рычаги давления на него, так что если тебя чем-то обидели напиши на мыло - постараюсь прижать. И ваще че там не так???
Mulder_1
18.07.2005, 10:14
философствовать я люблю ..)
как это возможно не дико звучит , однако это "оптимальное соотношение" должно быть ...
есть такая старая поговорка : Любую работу можно сделать быстро , качественно и недорого, но клиент должен выбрать всего два параметра.
отсюда я делаю следующий вывод : всегда должно быть соотношения цена конфигурации, объем базы (скорость роста), функциональность , удобство пользования и время разработки,
-со стороны заказчика : садить тупую "блондинку" оператора не будет выгодно так как она не поймет удобство_пользования и значит не оценит функциональность...
-со стороны исполнителя : если исполнитель видит тупую "блондинку", он обязан поставить в известность заказчика о "профнепригодности" персонала...
Оценивать ценнтость конфигурации должен представитель заказчика, который хорошо разбирается в предметной области т.е. знает что ему нужно (т.е. постановщик задачи со стороны заказчка)...
а на счет числового показателя ... интереская идея ... надо будет как-то формулу вывести ..)
з.ы. да нет ... дело не в том "жирный клиент" или "нестранный клиент"... странно как то получилось ... сделали предложение, предварительное ТЗ, вроде уже прорабатывать всю схему начали , а он отказался ...