[ОТВЕТИТЬ]
29.06.2006 13:56
AlexLog
 
Это просто песня - на ЦО как только бухи начинают генерацию - все остальные просто курят... Может кто напильничком подправлял ?
29.06.2006 15:36
OlegON
 
А в чем затык, не смотрел? Я помню, кто-то не обращал внимание, что проверка "новая цена больше предыдущего прихода" проверка стояла, причем ненужная, а она дорого стоит... Может и тут какая-то ненужная проверка долбится?
30.06.2006 11:36
AlexLog
 
Ну и што ? больше ни у кого затыков нету ???? Странненько..... или нихто не пользует ентот замечательный функционал ?
30.06.2006 11:39
Mtirt
 
Видимо для России он не особо актуален.
20.07.2006 17:02
Alex
 
Просто вбухали в систему, получился офигенный функционал и хоть бы спросили, а оно надо клиенту. также как и все эти 150 отчетов.
Мы ,например , стали резко работать по заявленному функционалу на бумажный бизнес. Видимо для России все таки супермаг не актуален.
Изображения
Тип файла: jpg Ежик.jpg (11.4 Кб, 391 просмотров)
Тип файла: jpg Ежик.jpg (11.4 Кб, 391 просмотров)
20.07.2006 17:47
Mtirt
 
В России тоже разные магазины и разный учет. У меня более 20 магазинов и одно юр.лицо - у меня одни проблемы. У какого-нибудь ЧП Пупкина - магазинчик в двумя кассами и совсем другие проблемы. Бухгалтерский учет разный, документооборот жестко не регламентирован. У меня оплачивается одной платежкой 40 поставок, а то и больше. Зачем мне функционал генерации платежных документов? А Супермаг актуален, но например мы его на 100% никогда использовать не будем - ну не нужны нам сорта и размеры.
20.07.2006 18:49
akonev
 
каждый из отчетов, который есть в супермаге, кто-то когда-то заказал. конкретно вам он может быть и не нужен. но это не значит, что он плох сам по себе.
то же самое касается и любого другого функционала, включая платежи.
платежи в супермаге не идеальны. я видел и лучшие варианты реализации.
но тем не менее, при определенных условиях их можно эффективно пользовать. у меня есть реальные внедрения, где их пользуют. но я не видел живых систем, где пользуют генерацию.
возможно, вы в самом деле напоролись на функционал, который не особенно популярен. он работает по некоторому ТЗ конкретного клиента. и мало кому еще нужен. бывает. ну дак в самом деле, как спрашивал олег, попробуйте найти: в чем затык?
потираньте манагера: для кого делали эту бодягу? по какому ТЗ?
похоже, что мало кого из полутора сотен админов, здесь тусующихся, эта тема волнует.
в россии вообще большинство прогоняет платежи через 1С, потому как 1С стыкуется с очень многими клиент-банками.
21.07.2006 00:14
OlegON
 
Цитата:
Alex Просто вбухали в систему, получился офигенный функционал и хоть бы спросили, а оно надо клиенту. также как и все эти 150 отчетов.
Мы ,например , стали резко работать по заявленному функционалу на бумажный бизнес. Видимо для России все таки супермаг не актуален.
Насчет 150 отчетов - просят еще, поверь. Пишут, дописывают, придумывают новые... Отчетность - великая вещь. И сколько бы ее не было - будет всегда мало.
Насчет актуальности - полгода назад или даже раньше была тысячная официальная инсталляция СМ2000, еще вопросы? Я не знаю, что у тебя за магазин, но я лично ставил СМ2000 чуть ли не в киоск. И люди были довольны. С ростом объема магазина и сети, запросы к функционалу растут в геометрической прогрессии. Чувствую, что неопытность влияет на ваше отношение к продукту. Я работаю с СМ2000, дай Бог памяти с 1.012. Знаете, как я ругался раньше? Программеры просто выли. Я даже через Memproof его прогонял. Но со временем, после того, как начал вникать и сравнивать (через меня прошло достаточно много аналогичных продуктов, я импортом, например, занимаюсь), наделал своих ляпов, пришло некоторое понимание философии разработки СМ2000, которую я теперь уважаю. И не так она плоха, как может показаться, когда только поставил и испугался. Я бы не стал его защищать, если бы был неправ. Просто бы прошел мимо. Не на рекламу работаю.
21.07.2006 00:17
OlegON
 
Цитата:
Alex Мы ,например , стали резко работать по заявленному функционалу на бумажный бизнес. Видимо для России все таки супермаг не актуален.
Кстати, в чем проблема-то? Может проще вопрос конкретный задать, чем жаловаться не по существу? Лучше в отдельной теме, если не по платежам.
25.07.2006 17:43
sotniku
 
Глюк по платежам -
провели по накладной платеж в центральной базе, после чего эту же накладную кто-то повторно высылает из подчиненной базы в центральную. В предыдущей версии в такой ситуации почтовик возвращал ошибку (точно не помню, вроде бы ошибка во время выполнения триггера SMDOCPAY - что-то вроде запрещено изменять накладные, по которым проведены платежи). Сейчас все успешно проходит (Супермаг 1.024.3 СП4) - без всяких ошибок накладная пересылается. После чего в базе эта накладная опять попадает в список документов, по которым не проведен платеж, бухи проводят платеж повторно - получается переплата. Проверил - все триггеры включены.
25.07.2006 17:52
OlegON
 
Цитата:
sotniku Глюк по платежам -
провели по накладной платеж в центральной базе, после чего эту же накладную кто-то повторно высылает из подчиненной базы в центральную.
Кто-то еще может это подтвердить?
25.07.2006 18:13
AlexLog
 
Я могу . А кто-нить исчо платежи генерит ?
25.07.2006 18:56
AlexLog
 
From: [email]v.petrov@servplus.ru[/email] [mailto:v.petrov@servplus.ru]
Sent: Tuesday, July 25, 2006 5:01 PM
To: [email]A.Logash@retorsia.com[/email]
Cc: [email]tsanswer@servplus.ru[/email]
Subject: RE: Вопрос по привязке платежей к накладным в сети



Здравствуйте,

Ошибка зарегистрирована №SMORA00002638


Это конечно здорово, что она зарегистрирована... Че делать-то ?.. Могет кто подскажет - тригерок какой влепить, или что исчо. Платить то лишнего поставщикам не хоцца...
25.07.2006 20:20
OlegON
 
На самом деле кромсать что либо чревато... Ибо при следующей генерации БД не оберешься. НО, простая мысль, если срабатывал предыдущий триггерок, почему бы его не списать, особенно, если структура не изменилась?
26.07.2006 09:19
AlexLog
 
Еще проще мысль (тока как сделать) заставить 57 проверку срабатывать и для почтовика, а не только для пользвателя. Тоже мне "всегда запрет". А вот и не всегда... прст...
26.07.2006 09:23
OlegON
 
Тоже мне "проще" :) Они все внутри зашифрованных хранимых процедур...
26.07.2006 09:46
AlexLog
 
Тож мне шифровальщики, шифруешь - так пиши корректно. *04
26.07.2006 09:49
OlegON
 
Триггер не пробовал вернуть?
*161
10.10.2006 14:12
KOT
 
Цитата:
Это просто песня - на ЦО как только бухи начинают генерацию - все остальные просто курят... Может кто напильничком подправлял ?
Боюсь ошибиться, если речь о сети и ЦО-принципиально, то я пасс..
Сам на одиночном *02 , так вот: платежи у бухов генеряться нормально, остальные работают не замечая этого. Только вот пришлось как-то за пол-года у приходов в шапке редактировать пору полей... пришлось опустить статус у платежей привязанных, а потом 6 часов до пуска рассчетов ночных не хватило что б поднять статус у платежей! *01 пришлось прибегнуть к принципу РАЗДЕЛЯЙ И ВЛАВСТВУЙ по одному поставщику разбираться отдельно и за несколько дней. *04
18.10.2006 16:58
nk222
 
У меня в почтовике ошибку выдает, что документ имеет ссылки на полатежные документы. Но после этой темы мы начали проверять и нашли кучу накладных по которым оплата была дважды. Но проверка срабатывает. Что делать?
19.10.2006 15:16
AlexLog
 
Дописывать, дописывать и исчо раз дописывать ! Подтвеждаю - генерятся дважды и трижды ! Если с магаза запулить накладную отвязывается фин основание нах. Мы так слегка попереплачивали поставщикам.... Ужас нах , хорошо до руководства не дошло - разгребли потиху *01
25.12.2007 09:36
nk222
 
Очень медленно проводяться платежи в супермаге. 100 платежей порядк а 6 часов, 1 платежка порядка 5 минут. Это только операция смены статуса с Черновика до Принят. В дальнейшем планируем 150-200 платежей.Как увеличить скорость проведения платежей хотябы до 1 минуты? У всех так медленно проводяться?


SM2000 1.024 sp 6
Oracle 8i
база 60 Гб
Windows 2003 EE
Xeon 2*2,8 ГБ М2
ОЗУ 4 Гб с ключем /3Gb
09.03.2010 13:47
Sullen
 
Проведение платежей - тормоза тоже! Виновата вьюшка - SMVatrateROEOImpl.
Select Count(*) From SMVatrateROEOImpl; - 30-45 сек. А вот используется ли она ещё где-то?.. Не повлияет ли на что-то после изменения. В ней "Union" тормозит, "Union All" на ура пролетает. Жаль в логике работы всей процедуры не разобрался пока.
31.03.2010 08:10
Sullen
 
Создал материализованное представление на основе запроса из SMVatrateBaseROEOImpl с именем SMVatrateBaseROEOImpl_M и подставил в запрос по SMVatrateROEOImpl. Пока бухи счастливы... Может немного неправильно это, но работает...
31.03.2010 09:08
OlegON
 
Цитата:
Sullen Создал материализованное представление на основе запроса из SMVatrateBaseROEOImpl с именем SMVatrateBaseROEOImpl_M и подставил в запрос по SMVatrateROEOImpl. Пока бухи счастливы...
Какая версия СМ? Приведешь DDL? Как подставлял? Query rewrite или правил что-то? Мне это не нужно, но вдруг кому-то...
20.05.2010 06:47
Sullen
 
СМ 1.026.2sp1
CREATE MATERIALIZED VIEW SUPERMAG.SMVATRATEBASEROEOIMPL_M
TABLESPACE USERS
CACHE
NOLOGGING
NOPARALLEL
BUILD DEFERRED
REFRESH COMPLETE
START WITH TO_DATE('03-апр-2010','dd-mon-yyyy')
NEXT trunc(sysdate) + 1
WITH PRIMARY KEY
ENABLE QUERY REWRITE
AS
Select V.DocType, V.ID as DocID, V.VATRate
from SMPayOrdersVAT V
union
Select T.DocType, T.DocID, T.TaxRate as VATRate
from SMSpecTax T, SMTaxIdentity I
where T.TaxSum > 0
and T.TaxID = I.TaxID
and I.IdentId = 0;
Правда, хотя и "ENABLE QUERY REWRITE", по некоторым причинам просто заменил имя "SMVATRATEBASEROEOIMPL" на "SMVATRATEBASEROEOIMPL_М" в представлении "SMVATRATEROEOIMPL". 2 месяца уже... пока нормально всё...
20.05.2010 11:05
Propil
 
после апгрейда базы ЦО с Oracle 9i на 10g платежи стали проводиться за секунды
Опции темы


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

 

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