Makssoft

сообщений: 17619 21.08.2008 09:38

Iriss, так Вы потому и не видите (и не увидите), что Вы вводите совсем не то, что я и совсем не так, как я и результат по составу информации у Вас совсем не такой.

Макссофт, зато вы все видите!

В 1С тоже есть з-отчет, я просто им не пользуюсь.

Я не понимаю, что вы пытаетесь сказать.

Что программа ваша лучше и работать на ней быстрей и приятней??

Макссофт, ДА!!!

Iriss, ну при чём здесь Ваша и моя программа?

Каждый написал как и в чём он работает и за какое время. Что Вы ещё от меня хотите? Вам я ничего не пытаюсь сказать более, чем сказала.

Приятней и быстрей работать в той программе, в которой есть такой функционал, о котором я написала. Знаю, что есть во многих программах, есть ли в Вашей - не знаю.

"В 1С тоже есть з-отчет, я просто им не пользуюсь." - ну и на здоровье Вам, обсуждение велось об обработке "малышей", когда все зет-отчёты вводятся, к чему было Ваше выступление, если Вы этого не делаете, непонятно.

А какая разница вводят ли все з-отчеты или один, общий за месяц..

Ну это я так, сама с собой поговорила.

Действительно, сама с собой. Если Вы не видите разницу в автоматизации функций, то это Ваша проблема. Программа ли сделает 100 проводок с файла банковской выписки или Вы их будете сами ваять (любыми методами: копированием ли каждой или вызовом группы и т.д.) - разница есть и очень существенная.

Да я тут вроде только про зет-отчет говорила...

Разницу я вижу, но не факт, что ваша автоматизация, о которой вы на каждом заборе пишете, лучше моей.

Пусть Ваша автоматизация будет лучше. Только сдаётся мне, что импорта банковской выписки Вы даже не видели.

о которой вы на каждом заборе пишете...

По десять раз

И что??

Вообще-то я и распечатку банковскую не смотрю, так как никаких выписок не ввожу нигде

Starina, вы преуменьшаете

Как всегда тема превращается в базар-вокзал

21.08.2008 20:33

А при чём здесь банковский импорт?

maksoft kā saka "pri tom" ka automātiskās dokumentu piesaistes veidojas tikai par ideāli pareizām un prezīzām skaitļu un zīmju kombinācijām

Tātad mans viedoklis kas notiek Lattelakom sistēmā:

Automātiskais datu inmports ieskaitot automātisko rēķinu apmaksas piesaisti pēc pamatojumiem maksājumu uzdevumu tekstos

līdzko kaut viena zīme vai atstarpe maksājuma uzdevumā norādītajā pamatojuma nesakrīt ar sistēmā esošo rēķina Nr- piesaiste rēķinam automātiski netiek izveidota rēķins stāv neapmaksāts kaut gan ir sem apmaksāts. Vēl modernās sistēma ( kā pārliecinājos līdzinot norēķinus ar darījumu partneriem) šis neatpazītās summas "uzkar" avansu kontā -tatad pat citā norēķinu kontā kā rezultātā cilvēkam ar saprātu neizskatot automātiko datu importa un maksājumu automātiskās piesaistes rezultātu pasakaini brīnumi veidojas.

Bija gadījumi kad nespēju pārliecināt programmu izstrādātājus ka ne vienmēr maksājuma reģistrēšana sistēmā pirms rēķina atpazīšanas ir avanss- tas ir vienkārši maksājums kuram ievada brīdī datorā nav atrodams korekts pamatojuma dokuments un vēlāk pārbaudot dokumentus var tikt atrasts un piesaistīts- bet šī iespēja netiek dota . Ja nav konkrētais rēķins maksājuma izveides brīdī- tātad avanss un viss.(PZ Apvārsnī ar kuru strādāju šis bardaks ar nepamatotiem avansiem brīvprātīgā piespiedu kārtā neveidojas jo ir vienkārši maksājuma dokuments kura piezīmēs ieraksta tektu ko redz bankā un pēc tam nemuļļājoties pa avansu kontiem var veidot sasaistes )

Diemžēl atšķirībā no Jums Maksoft esmu tikai grāmatvedis un visas ši problēmas skatu no grāmatveža ar garu apjomīgu un daudzveidīgu praksi viedokļa nevis no programmētāja viedokļa.

Arī darbiniekiem saku ka nav jēdziens "DATORS izdarīja vai dators sarēķināja"- bet es grāmatvedis pārbaudīju vai nepārbaudīju korektu informācijas ievadu datorā un ievdīto datu pareizību.

Nu ļoti ļoti reti - tehnisku iemeslu dēļ dators kaut ko dara greizi-parasti kļūdās cilvēks .:-)

Guntagermane, здесь речь шла об импорте банковской выписки, которую предоставляют интернет-банки и которая никакого отношения к счетам в финансовой бухгалтерии не имеет (связь эту оплаты со счетами бухгалтер осуществляет позже, после импорта).

Относительно Латтелекома, не знаю КАК они импортируют платежи, но это совсем иной импорт и об этом здесь речи нет. Могу предполагать только, ввиду того, что сама программировала подобный для фирмы кабельного телевидения. По этому импорту с банками заключался спец. договор, в котором оговаривался особый формат. И этот импорт осуществлял связку оплаты со счетами. Поскольку эксплуатация программы осуществлялась не один год, имею представление о процессе. Количество необработанных платежей или неверно обработанных имелось, конечно (это зависит и от информации, которую передаёт плательщик). Работник, осуществляющий подобный импорт, занимается выяснением происхождения ошибок. Очень долгое время оплаты обрабатывались без импорта (с очень высокой скоростью ввода и практически безошибочной) и долго решали переходить ли на обработку платежей путём импорта файлов. Так вот, когда по истечению времени сравнили оба метода, всё же импорт файлов имел преимущество.

Ещё раз повторюсь, что выше сказанное не имеет НИКАКОГО отношения к стандартному импорту банковской выписки. Там ошибок просто не может быть никаких. Может недоставать информации (если плательщик не передаёт свой персональный код или регистрационный номер, а если передаёт, то и аналитика будет), может не импортироваться по полноте, если сделаны не все настройки по операциям, всё это вопросы отладки и верного программирования, но когда всё отлажено - нет никаких проблем (в базе данных имеются все проводки как в банковской выписке). Очень многие бухгалтеры это делают и довольны, я в том числе.

"Automātiskais datu inmports ieskaitot automātisko rēķinu apmaksas piesaisti pēc pamatojumiem maksājumu uzdevumu tekstos

līdzko kaut viena zīme vai atstarpe maksājuma uzdevumā norādītajā pamatojuma nesakrīt ar sistēmā esošo rēķina Nr- piesaiste rēķinam automātiski netiek izveidota rēķins stāv neapmaksāts kaut gan ir sem apmaksāts. " - а вот это полный бред, этого нельзя делать - связывать объекты по текстовому реквизиту. Ошибок можно получить немеряно!

Rakstīju tādēļ ka konflikta būtība ar lattelekum :

Nevaram atrast maksājumu jo nepareizs pamatojums maksājumā ir rēķina Nr 89857802 jābūt 8985780-2

Kas tad varēja būt par iemeslu ja dēļ šis vienas svītriņas strīdējos ar Lattelekom 2 nedēļas tai skaitā sūtīju faksus lai vieglāk atrast noklīdušo maksājumutaču beigās saņēmu rakstiskus brīdinājumus ka nav samaksāts rēķins

Vienkārši ar galvu strādājošam grāmatvedim šāda novirze dokumenta Nr atsaucē nekad nav šķērslis apmaksas atrakstīšanai Mēģināju problēmu norakstīt uz tehniku nevis cilvēkiem.

Principā visus šos atvieglojumus grāmatvežu darbā atzīstu, pieņemu iespēju robežās izmantoju vienīgi palieku pie viedokļa ka tikai dators šo darbu nevar veikt ir taču nesakritības jāskatās arī cilvēkam kurš strādā ar dokumentiem nevis tikai jāsūta vēstule " jūs neesat samaksājuši" un jārēķina soda naudas.vaipat vēl trakāk- jāatslēdz telefons.

Katrā ziņā datorprogrammu nīdējos un anlfabētos sevi nepieskaitu jo pirmos uzskates reģistrus ar datoru sāku gatavot jau ap 1993 gadu ....

Ну я уже писала, что программировать подобным образом нельзя (если это действительно так, как Вы описываете). Нельзя идентифицировать оплату счёта 8985780-2 по содержанию операции, в котором написано "89857802". Это непрофессионально.

Тут недавно задавался подобный вопрос : можно ли идентифицировать операцию по цели платежа в банковской выписке. НЕЛЬЗЯ этого делать - господя, где учились те программисты, которые это делают.

"связь эту оплаты со счетами бухгалтер осуществляет позже, после импорта" - тогда вообще не вижу резона. Сидеть перелопачивать все платежи и привязывать - мрак какой-то.

Сидеть перелопачивать все платежи и привязывать - мрак какой-то.

Kā tad Jūs konstatēsiet faktu kad par 10 pavadzīmēm samaksā naudu 11 izlaiž un tad atkal maksā atkal kautko izlaiž....

Ai Ai cik bieži tā notiek.



Sekmīga debitoru kreditoru uzskaite ir tikai konkrēti piesaistot konkrētos apmaksātos dokumentus nevis kaut ko uz to pusi jeb vispār atlikumu uzskaitīt kopsummā bez analītikas pa dokumentiem.

Ne velti pēdējos gados lielākajā daļā uzskaites programmu šī iespēja tiek aizvien pilnīgāk iestrādāta (kā nofiksēju no izdrukām pat lētajā Zalktī ir). Gadus 5-10 atpakaļ tas vēl bija programmas "navarots"

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

Связывать с оплатой нужно или не нужно только дебиторские счета, при готовых проводках по банку это гораздо меньше работы, чем вводить ВСЕ проводки по банку и опять же связывать руками (у Вас уже готовы банковские комиссии, Ваши перечисления, съём наличных в банкоматах и т.д., а также поступления денег с аналитикой).

Если Вы примеряете банковский импорт в больших размерах, например, 10000-30000-50000 платежей (услуги, оказываемые частным лицам), то это совсем ИНОЙ банковский импорт и там не надо перелопачивать все платежи, читайте что я написала по этому поводу выше.

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

"Связывать с оплатой нужно или не нужно только дебиторские счета" - у меня в выписке приход только с дебиторских счетов. А банковские комиссии одной суммой за день ввести, скопировав

предыдущую проводку - ну прям адский труд.

"у Вас уже готовы ... Ваши перечисления, " - мои перечисления тоже с 3-мя уровнями аналитики идут. Они будут готовы так, как мне нужно? Сумлеваюсь.