[ОТВЕТИТЬ]
29.03.2015 11:32
alwaysright
 
Здравствуйте. Открываем дискуссию. Сравнивать предлагаю помодульно. Я показываю как реализовано тот или иной бизнес процесс в Меркурии, а кто нибудь мне помогает с СуперМагом.
Для начала возьмем ретробонусы. В меркурии есть специальный журнал расчета ретробонусов.



в нём документы. Каждый документ - расчет ретробонуса.



Для автоматической настройки правил расчета ретробонусов - существует журнал правил.



Правила утверждаются коммерческим директором. Менеджерам остаётся только раз в месяц нажать кнопку "Рассчитать по правилам". Снимаются вопросы сговора категорийных менеджеров с поставщиками.
После того, как бонус расчитан, создается расход "Маркетинговых услуг" на поставщика. И начисляется долг. Бухгалтерия ставит оплату к этому расходу. В финансовом модуле видно, все ли бонусы оплачены.
29.03.2015 11:44
alwaysright
 
Второй модуль из свеженьких. Автоматическое списание упаковочных материалов (пакетов, плёнки, и т.д.)
Категорийные менеджеры заводят в системе "Правила Списания Тары". Выглядят они примерно так



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



Если магазин не укладывается в "нормативы" - недостача упаковки вешается ему в ревизию.
29.03.2015 11:52
alwaysright
 
Вот интересная фича, для директора и собственника фирмы.
В Меркурии, как и в других программах, существует закрытый период. У каждого склада свой. Но никто не гарантирует, что сговор админа и бухгалтера произойдет и задним числом (поменяв период) исправят какие нибудь документы. Для клиента, озвучившего такое опасение мы сделали вот эту штуку



смысл в том, что перед закрытием периода печатается этот документ (поля настраиваются из конструктора) и кладётся в сейф директору. После этого период закрывается. В любой момент директор сможет пересчитать финотчет и сравнить с бумажным в сейфе. Если данные расходятся - значит период открывали и чего то там меняли.
29.03.2015 13:57
AndreyZh
 
Без умолку безумная девица
Кричала: "Ясно вижу Трою павшей в прах!"
Но ясновидцев - впрочем, как и очевидцев -
Во все века сжигали люди на кострах. (с) В.С.Высоцкий

Хотите с кем нибудь подраться? Не трогайте "хозяев" - да они с неизвестными новичками скорее всего не станут "марать свои руки"... Рискните, если не "западло" с людьми с "соседней улицей", т.е. со мной - правда система по инструментарию не претендует на супергипермегасистему автоматизации, но на её полянке, вы же там так собираетесь "пастись" - пожалуйста.

... или подождите, м.б. кто-то и решит вас "поразмазывать"...
29.03.2015 16:18
alwaysright
 
а у вас какая программа?
29.03.2015 16:44
AndreyZh
 
Цитата:
alwaysright а у вас какая программа?
Учетно-аналитическая для малого бизнеса: опт, розница, производство, страховой бизнес, реализация нефтепродуктов, ... Ладно, раз Вы не удосужились даже взглянуть на "назойливую муху", ссылок Вам дал достаточно позвольте прекратить диалог в Ваших темах.
29.03.2015 17:01
alwaysright
 
Цитата:
AndreyZh Учетно-аналитическая для малого бизнеса: опт, розница, производство, страховой бизнес, реализация нефтепродуктов, ... Ладно, раз Вы не удосужились даже взглянуть на "назойливую муху", ссылок Вам дал достаточно позвольте прекратить диалог в Ваших темах.
Простите великодушно. Не хотел вас обидеть. Но не вижу ссылок...
30.03.2015 07:43
OlegON
 
Цитата:
alwaysright Простите великодушно. Не хотел вас обидеть. Но не вижу ссылок...
КИС Lack УС Land
30.03.2015 08:13
OlegON
 
Боюсь, оппонентов Вы всех распугали, вывалив такое нагромождение текста и картинок. Форум - есть форум, гигантские транспаранты никто читать без конкретной заинтересованности не будет, как и писать аналогичные. Лучше было бы построить диалог следующим образом: выбираете в теме Супермага какой-то недостаток и сравниваете здесь, как бы сделали это в своей системе.

AndreyZh, прошу больше не комментировать поведение "хозяев" и "марания рук", для нарушений правил есть соответствующая кнопочка, а загадывать вперед не надо. Предлагаю создать еще одну тему сравнения, например, взять скрины отсюда и вызвать "Меркурий" на бой.

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

С ретробонусами и списанием тары, если честно, ничего не понял. Возможно, что кто-то еще поможет разобраться.

Давайте лучше принципиальное разберем.

1. Есть ли описание структуры БД? (в Супермаге есть)
2. БД Firebird... Почему не Postgres хотя бы? С Oracle в Супермаге тут не сравнимо.
3. Каким образом обмениваются пакетами базы? Есть ли возможность файлового обмена? (В Супермаге есть)
4. Требуются ли регулярные процедуры, исключающие одновременную работу с БД пользователей? (В Супермаге это перенос аналитики, занимающий около 10 минут, выполняется в зависимости от необходимости эту самую аналитику предрасчитать)
5. Есть ли аналитическое хранилище? В Супермаге отчеты в достаточно большом их количестве выполняются по предрасчету.
30.03.2015 08:43
alwaysright
 
по пунктам отвечаю:
1. Описания структуры базы нет, по причине лени. Но саму структуру не скрываю. Будет запрос от сообщества - сделаю.
2. Так сложилось исторически, у нас двухзвенка и поменять БД крайне сложно. Но по самому крупному клиенту (70 Супермаркетов, 100 одновременных пользователей), база за 5 лет вместе с чеками весит 120 Гигов. На двухпроцессорном Ксеоне с ССД проблем с производительностью нет.
3. Обмен с кассой файловый, распределенной БД у нас нет. Управляющие магазинами работают в терминале.
4. Отключать пользователей нужно только для обновления версии базы данных. И то не в каждом случае (когда тяжелые индексы добавляем)
5. Предрасчитанная аналитика есть. Отдельная БД (можно на другом сервере) и набор скриптов, её заполняющий. Но для гурманов рекомендуется OLAP.

По поводу истории изменения документов - храним все. Даже штрихкоды измененные, не то что цены/суммы. Регулярно история выгружается в отдельную БД. ( у того же клиента, файл с историей 180 Гигов)
30.03.2015 10:00
OlegON
 
1. Дело не в сообществе, а в том, что клиенты любят многое делать под себя (отчетность)
2. Тут сказать нечего, у меня столь же исторически сложилось предубеждение против Firebird. Точнее, против его использования в больших нагруженных проектах. А в небольших я люблю MySQL.
3. Вот я про распределенную БД. Сильная сторона Супермага - файловый обмен в распределенной структуре. Что я думаю о том, как это сделано - второй вопрос, но он есть и работает. Можно хоть на флешке отвезти при потери связи с какой-то деревней. Тут у вас серьезный минус, которым Супермаг выдавливает 1С и, соответственно, обыгрывает вашу систему.
4. 5. Вот тут, судя по всему, собака порылась в неразвитой аналитике? Поскольку сущности транзакций и документов часто различаются, переносить документы в аналитику нельзя либо без существенных потерь в производительности, либо без остановки пользователей. OLAP можно прикрутить практически к любой БД с открытой структурой. В Супермаге перенос аналитики выполняется одной кнопкой или по расписанию.

Спорить о разнице скриншотов и местах, куда надо попасть мышкой в той или иной программе, можно до хрипоты и в целом это больше религиозные споры с минимальным результатом. Аналогично не раз уже схлестывались тут и с Астором и с кем-то еще по вопросам отражения бизнес-процессов в софте. Сравнивать разное очень трудно. Сказать, что лучше - тем более, поскольку на вкус и цвет. Эргономика тоже вкусоцветовая, но я, например, люблю горячие клавиши, которых в Супермаге нет. Собственно, я бы вообще предпочел консоль :) Это к чему - начните с глубокого, ядра программы, а все остальное, при сильном ядре, навешивается достаточно быстро. Представьте себе юзера, работающего на ужасных каналах данных, старом железе с 1000 кассами и 6 терабайтами данных. Обычно сразу слабые места вылезают.

Я бы сейчас стал делать кроссплатформенную софтину, на волне импортозамещения... Пошла бы, как по маслу, я думаю. Т.е. Linux на рабочих местах и на сервере, втыкаете собственнику, что он теперь от Запада и лицензий на рабочие места не зависит, винду только бухам и все в шоколаде. По базе, не знаю, попробовал бы все же Postgre, ее сейчас сильно поднимут.
30.03.2015 10:32
alwaysright
 
Я тоже люблю интерфейс с кнопками. На днях запишу видеоролик, как работают быстрые клавиши и интерфейс в целом.
Перенос аналитики сам по себе ресурсы не загружает. Загружает предварительный её пересчет. Но это можно на другом серваке делать. Механизмы у нас все есть, и по кнопке и по скриптам в управлении задачами.
Единственное, что я пока не хочу делать - распределенку. Очень сложно сделать хорошо, а плохо и так у многих сделано. В совсем удаленной деревне можно вообще без бэка обойтись. Новые цены привозить на флешке, на ней же забирать чеки. А ценники и ревизии - с кассового сервера.
В меркурии очень партионный учет. Он не даст сделать расход, без строгой привязки к партии. И внутренние перемещения, жестко связанные триггерами приходы с расходами. А корректировки в офисе предыдущих дней... Нет. Боюсь, слишком многим придется пожертвовать ради распределенки. Причем именно тем, что приносит строгий порядок.
По поводу таких огромных баз данных... 1000 касс у нас не было, максимум 250. И это за 5 лет 120 гигов данных. А ведь есть механизмы архивации старых периодов... Но опять повторюсь. 120 гигов летает на 24 ядрах, 64 Гигах оперативы и ССД дисках. Из транзакционной базы какая нибудь оборотка по группе товара за год больше 5 минут не строится.
Дизайнер отчетов есть встроенный для гиков. Пишешь sql и на fastreport форма. Все в базе сохраняется, правами пользователя открывается.
Есть Бизнес-Анализ. Пользовательский генератор отчетов. Как в супермаге, но со своими ништяками. Например можно склеить два отчета по каким то полям, добавить формулы и сделать сводную таблицу. Можно результат анализа сохранить в базе, с привязкой к справочникам. Например посчитали какой нибудь коэффициент оборачиваемости и сохранили его как доп. поле в ассортименте. Удобно.
Ссылку дать не могу.
30.03.2015 12:17
OlegON
 
Кто это сказал, что в удаленной деревне можно без бека? Я для примера подразумевал отсутствие связи в принципе, но это не значит, что там одинокая касса стоит, принимать товар как? Насчет того, чем придется пожертвовать, никто не уговаривает, но имейте ввиду, что будете в конце очереди тех, кто хоть как-то сделал распределенку. Что касается того, кто и как летает, то 120 гигов должно летать на 4 ядрах, 16Гб оперативки и обычных винтах, причем, на этом же сервере будет работать что-то еще. В противном случае, ваша романтика будет разбиваться о то железо, которое будут предлагать в той нише, на которую Вы ориентируетесь. Я давно матерюсь на нищебродов, но все равно вместо серверов ставят хз что.
30.03.2015 12:20
alwaysright
 
Транзакционка то летает. Аналитике нужна мощность.
30.03.2015 12:25
OlegON
 
Нужна, транзакционка в 100 человек на том, что я сказал, может и не полететь. А давать будут барахло, а не железо, привыкайте к реалиям :(
А на том, что сказали, только уж что-то редкое не полетит.
30.03.2015 13:20
FinSoft
 
Олег, хотел спросить.
1. Что составляет основной объем базы данных в Супермаге? Я правильно думаю, что это чеки?
2. Если чеки, то они запоминаются в одной огромной таблице?
3. Партии двигаются чеками или предусмотрены какие-то сводные документы?

После прочтения некоторых постов на этом форуме, у меня возникли смутные подозрения насчет базовых принципов организации базы данных.
30.03.2015 13:26
alwaysright
 
Цитата:
FinSoft Олег, хотел спросить.
1. Что составляет основной объем базы данных в Супермаге? Я правильно думаю, что это чеки?
2. Если чеки, то они запоминаются в одной огромной таблице?
3. Партии двигаются чеками или предусмотрены какие-то сводные документы?

После прочтения некоторых постов на этом форуме, у меня возникли смутные подозрения насчет базовых принципов организации базы данных.
Да, и мне интересно. В меркурии партии двигаются сводными документами на основе чеков. А чеки в двух огромных таблицах. Заголовок и тело чека.
30.03.2015 13:31
Mtirt
 
Цитата:
FinSoft Олег, хотел спросить.
1. Что составляет основной объем базы данных в Супермаге? Я правильно думаю, что это чеки?
Нет, чеки обычно не самая большая таблица в Супермаге. Хотя и не маленькая.
Цитата:
FinSoft 2. Если чеки, то они запоминаются в одной огромной таблице?
Таблиц несколько: заголовок чека, товарный состав, скидки, оплата банковской картой, еще что-то...
Цитата:
FinSoft 3. Партии двигаются чеками или предусмотрены какие-то сводные документы?

После прочтения некоторых постов на этом форуме, у меня возникли смутные подозрения насчет базовых принципов организации базы данных.
Партии двигаются документами. На основании всех чеков по магазину за день создаются так называемые "Кассовые документы" (один - для всех продаж, один - для всех возвратов товара и один - для безвозмездной передачи). Они и двигают регистры. В них информация о продаже свернута в разрезе товаров.
30.03.2015 13:52
Mtirt
 
Решила ответить на сравнение функционала.
Правда не поняла, почему сравнение начинается с ретро-бонусов.
Это точно не отправная точка в торговой системе.

Цитата:
alwaysright Здравствуйте. Открываем дискуссию. Сравнивать предлагаю помодульно. Я показываю как реализовано тот или иной бизнес процесс в Меркурии, а кто нибудь мне помогает с СуперМагом.
Для начала возьмем ретробонусы. В меркурии есть специальный журнал расчета ретробонусов.



в нём документы. Каждый документ - расчет ретробонуса.



Для автоматической настройки правил расчета ретробонусов - существует журнал правил.



Правила утверждаются коммерческим директором. Менеджерам остаётся только раз в месяц нажать кнопку "Рассчитать по правилам". Снимаются вопросы сговора категорийных менеджеров с поставщиками.
После того, как бонус расчитан, создается расход "Маркетинговых услуг" на поставщика. И начисляется долг. Бухгалтерия ставит оплату к этому расходу. В финансовом модуле видно, все ли бонусы оплачены.
Ну и еще мне лень делать скриншоты, поэтому я буду просто указывать на документацию к Супермагу. (Саму документацию можно найти в Хранилище Супермаг/Документация/)
Функционал в Супермаге есть, и, по-моему, выглядит также, как вы показали. Том 3. Пункты 8. и 9. Документации.
30.03.2015 14:00
Mtirt
 
Цитата:
alwaysright Второй модуль из свеженьких. Автоматическое списание упаковочных материалов (пакетов, плёнки, и т.д.)
Категорийные менеджеры заводят в системе "Правила Списания Тары". Выглядят они примерно так



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



Если магазин не укладывается в "нормативы" - недостача упаковки вешается ему в ревизию.
Спорный функционал. Хотелось бы увидеть нормативную базу на основании которой вы это делаете. Потому как на месте персонала магазина, в котором это используется, я бы отказалась платить недостачу, так как расчетные данные не подтверждаются документами. Да и источников ошибок хватает: программа считает подложки для печенья, подложек в наличии не было, печенье расфасовали в мешочки. В итоге магазин платит недостачу.
Бесплатный (для покупателя) упаковочный материал учитывается в Супермаге двумя способами: регистрация в чеке по нулевой цене и инвентарь. С первым способом всё понятно: строгий количественный учет. Во втором способе идет простое списание на издержки предприятия по мере израсходования материалов.
30.03.2015 14:02
Mtirt
 
Цитата:
alwaysright Вот интересная фича, для директора и собственника фирмы.
В Меркурии, как и в других программах, существует закрытый период. У каждого склада свой. Но никто не гарантирует, что сговор админа и бухгалтера произойдет и задним числом (поменяв период) исправят какие нибудь документы. Для клиента, озвучившего такое опасение мы сделали вот эту штуку



смысл в том, что перед закрытием периода печатается этот документ (поля настраиваются из конструктора) и кладётся в сейф директору. После этого период закрывается. В любой момент директор сможет пересчитать финотчет и сравнить с бумажным в сейфе. Если данные расходятся - значит период открывали и чего то там меняли.
Ну здесь совсем просто. Ничто не мешает распечатать последнюю страницу сводного товарного отчета и положить её в сейф. Или любой другой отчетной формы, отражающей остаток товара. А еще есть отчет "Причины изменения сальдо остатка". Или журнал истории документов. Инструментов контроля хватает...
30.03.2015 14:17
FinSoft
 
Цитата:
Mtirt Нет, чеки обычно не самая большая таблица в Супермаге. Хотя и не маленькая.

Таблиц несколько: заголовок чека, товарный состав, скидки, оплата банковской картой, еще что-то...

Партии двигаются документами. На основании всех чеков по магазину за день создаются так называемые "Кассовые документы" (один - для всех продаж, один - для всех возвратов товара и один - для безвозмездной передачи). Они и двигают регистры. В них информация о продаже свернута в разрезе товаров.
Спасибо, понятно. А какая таблица самая большая (если не считать логи)? Я пытаюсь понять, в чем узкое место с производительностью, требующее применение мощных компьютеров, оракла в качестве хранилища данных и т.д. На встроенной базе я бы просто поделил чеки на файлы по периодам, а нужные для анализа сводные итоги сваливал в отдельные таблицы. По сравнению с оптом, в рознице сильно должно упрощать жизнь, что чеки задним число не корректируются. Что требует наибольших вычислительных ресурсов в Супермаге, если расход в парционном учете организуется 3 документами в день (ну плюс еще перемещения)? Или речь идет о больших сетях магазинов (несколько десятков или даже сотнях), а под остальных разработчики просто забились на вырост?
30.03.2015 14:36
OlegON
 
А никто не говорит про беспредельные ресурсы в Супермаге, о том и речь, что его сервера начинались когда-то с 512Мб памяти и это все неплохо работало. На магазинных базах все достаточно неплохо работает чуть ли не на десктопах, что сильно доставляет проблем админам, поскольку параллельно работающие пользователи ставят всякое дерьмо и все это начинает глючить. Но суть - урезание функционала, а не базы. Растет база, добавляете ресурсов и продолжаете на ней работать. База одна и та же, что в центральном офисе большой сети, что в одиночном магазине на две кассы. Надо справедливости ради отметить, что не только редакции Супермага меняются, но и редакции Oracle, как правило. Большим базам - больший функционал.
Самые большие таблицы - аналитика, т.е. предпросчет связей документов. Потом идет таблица спецификаций документов. Оракл позволяет прозрачно для софта партиционировать таблицы, т.е. резать их на куски, например, по датам. И уж возможностей отслеживания целостности данных и их восстановления в Oracle ведро.
30.03.2015 14:49
Mtirt
 
Цитата:
FinSoft Спасибо, понятно. А какая таблица самая большая (если не считать логи)? Я пытаюсь понять, в чем узкое место с производительностью, требующее применение мощных компьютеров, оракла в качестве хранилища данных и т.д. На встроенной базе я бы просто поделил чеки на файлы по периодам, а нужные для анализа сводные итоги сваливал в отдельные таблицы. По сравнению с оптом, в рознице сильно должно упрощать жизнь, что чеки задним число не корректируются. Что требует наибольших вычислительных ресурсов в Супермаге, если расход в парционном учете организуется 3 документами в день (ну плюс еще перемещения)? Или речь идет о больших сетях магазинов (несколько десятков или даже сотнях), а под остальных разработчики просто забились на вырост?
Если рассматривать средний российский супермаркет, то в нем не будет большой базы. Максимум 50 Gb, да еще лет за 10 работы.
Большие базы возникают в офисах торговых сетей.
Для грубой оценки можно умножить эти 50Gb на количество магазинов сети.
Почему Oracle? Сам продукт создавался (Олег меня поправит) еще до 2000 года. Там просто не было многообразия баз данных. По большому счету и выбрать можно было из Oracle и MSSQL. Создавался не на пустом месте: был Супермаг 2.6, использовавший таблицы Paradox. И использующие его магазины часто сталкивались с ограничением на размер таблицы и необходимостью обрезки данных. Поэтому, возможно и был выбран Oracle, как БД, которая могла работать с наибольшими базами, на тот момент.
30.03.2015 15:10
FinSoft
 
А какая статистика по необходимости администрирования баз данных Супермага (от количества рабочих мест)? Не считая поддержки харда.
1. Не требует администрирования.
2. Приходящий администратор.
3. Администратор в штате.
30.03.2015 15:15
OlegON
 
Я считаю, что "не требует администрирования" - это маркетинговый ход, оборачивающийся потом неудовлетворенностью от системы. Даже если пользователи пользуются только Excel, администрировать софт (ОС) все равно надо. Приходящий администратор устраивает всю линейку. В штат надо брать разработчика, если возникает потребность. Админ БД в штате особо и не нужен. И уж точно лучше взять вменяемого админа на неполную занятость, чем пионера в штат.
30.03.2015 15:16
Dim
 
у меня есть одиночный магазин, работающий с 2007 г. у них в штате ни программиста, ни сисадмина нет. раз в год-два звонят с какими-нибудь проблемами и все. в сети, естественно, сисадмин должен быть.
30.03.2015 16:05
alwaysright
 
Цитата:
Mtirt Спорный функционал. Хотелось бы увидеть нормативную базу на основании которой вы это делаете. Потому как на месте персонала магазина, в котором это используется, я бы отказалась платить недостачу, так как расчетные данные не подтверждаются документами. Да и источников ошибок хватает: программа считает подложки для печенья, подложек в наличии не было, печенье расфасовали в мешочки. В итоге магазин платит недостачу.
Бесплатный (для покупателя) упаковочный материал учитывается в Супермаге двумя способами: регистрация в чеке по нулевой цене и инвентарь. С первым способом всё понятно: строгий количественный учет. Во втором способе идет простое списание на издержки предприятия по мере израсходования материалов.
Если подложек нет и магазин нафасовал в мешочки - по мешочкам выйдет недостача, а по подложкам излишки. в ревизию скомпенсируются. По поводу спорности функционала - делалось под клиента. Посмотрел аналитику по этой таре за январь 15 года 380 тысяч рублей тары списано. (70 магазинов). Заказчик доволен. Говорит раньше больше тары уходило. Магазины сильно не возмущаются.
30.03.2015 16:09
alwaysright
 
Кстати, Пётр (не помню фамилию, продажник Сервисплюсовский) говорил, что клиенты не особо ведут в супермаге расчеты с поставщиками. Оставляют это на 1С. Так ли это? Расскажите про этот модуль в супермаге...
30.03.2015 16:12
Mtirt
 
Цитата:
alwaysright Если подложек нет и магазин нафасовал в мешочки - по мешочкам выйдет недостача, а по подложкам излишки. в ревизию скомпенсируются. По поводу спорности функционала - делалось под клиента. Посмотрел аналитику по этой таре за январь 15 года 380 тысяч рублей тары списано. (70 магазинов). Заказчик доволен. Говорит раньше больше тары уходило. Магазины сильно не возмущаются.
Я за 10 лет общения с Сервис+ перестала любить фразу "делалось под клиента". Мне сейчас интересно, если клиент попросит сделать кнопку полного уничтожения базы, вы её тоже сделаете?
Сервис+ пока не приведешь ссылки на нормативные документы, законы и приказы, регулирующие деятельность, не будут даже ТЗ рассматривать. А когда начнут, еще кучу аргументов из законодательства привести могут...
А что касается "магазины сильно не возмущаются", то подождите, найдется один грамотный администратор, и завозмущаются сразу все 70.


Опции темы


Часовой пояс GMT +3, время: 18:08.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.