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

А вот это хорошая функция в некоторых случаях!

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

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

Вот очень упрощенный пример того как это уже работает:
1. Заполнит реквизиты документа на основании фотки этого документа.
2. Поставит или предложит типовые проводки.
3. Поставит или предложит наиболее вероятные проводки для конкретного документа.
4. Заполнит проводки на основании электронных копий документа (например спецификации счетов в электронном виде - ЛМТ, Статойл и т.п.) и на основании заполненых классификаторов в программе. Например, для тех же счетов от Статойла - какую машину кто когда заправлял и что покупал на заправках и в зависимости от этого дебету 77, 75, 21 и применять ли коррекцию 80% к НДС для легковушек.
5. Заполнит недостающие проводки на основании уже заполненых и провереных бухгалтером проводок, товароведом товаров, менджером аналитических признаков или кем-там-еще-чего.

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

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

Ха-ха-ха. Ну вот положу я вам несметное количество чеков с разных уголков Европы и что вы с ними будете делать? Или переводчик тоже по умолчанию встроен в вашу прогу? И тут же определит, что это
а) заправка
б) стоянка
в) покупка запчастей
г) платные дороги (за которые приходит отдельный счет)
д) ремонт
е) водитель просто купил себе пива
А потом сам отследил маршрут и начислил суточные. Красота!

ну дык програмеры далеки от жизни буха

.....несметное количество чеков с разных уголков Европы....
un ne tikai Eiropa, Krievija arī- tur vispār jauki čeki
Un ne tikai alus
Un čeki no Polijas

un ne tikai Eiropa, Krievija arī- tur vispār jauki čeki
Un ne tikai alus
Un čeki no Polijas

Ага, и это тоже

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

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

Ну нет у меня клиентов транспортников.

Это как?

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

Но это пока что только теория. Ничего такого еще у нас не реализовано. Проблемы в реализации - не можем (на самом деле я тут не один на эту тему работаю) придумать нормальный GUI. Также еще не рассматривались варианты с иностранными чеками.

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

конечно, разобраться в разнообразии документов под силу только человеку, но Kenguri , если я прально поняла, за то, чтобы автоматизировать всё, что можно

считывание дока автоматом не так уж и нереально

товары же считываются по штрихкодам

докУменты тоже можно обозначить как-то и тут только человек управляет процессом
к примеру, заготовить наклейки типа "K1", "K2" ..., бух клеит их на документы (сортировка доков), затем, как там у Kenguri , подносит док к экрану и прога считывает код документа, смотрит в справочник: этому коду соответствует контировка и т.д. Что легче: вводить данные с документов или клеить наклейки?

это если с бумажек

можно настроить импорт однотипных документов электронно, например, если поставщик, акрамя бумажек, ещё и файл даст
у меня такой работает в складском учёте, сильно облегчает работу по вводу накладных, НО
тут же тоже есть засада, надо же, чтобы поставщик хотел этот файл давать :), тут кто в ком заинтересован

Так что простор для фантазий большой

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

Очень может быть. Этот алгоритм будет более-менее работать с обычными хозяйственными расходами в Латвии. Как у Вас - не знаю, не видел. Да и не все нужно автоматизировать и алгоритмировать. Порой проще ввести руками, чем научить программу. Но это меньшинство случаев.

На спор? Найдет кучу!

Не, со штрих-кода - неинтересно! Проще ввести сразу в прогу. Намного интереснее, если в системе также сохранится изображение этого документа. А признаки типовой проводки уже имеются в каждом документе - поставщик, тексты

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

Kenguri, tērējiet savu dārgo laiku un zināšanas kaut kam lietderīgākam, jo grāmatvedībā vienalga vienmēr būs vajadzīgs grāmatvedis ar loģisko domāšanu.
Tas, ko te aprakstiet, būs priekš datu ievades operatoriem...labākā gadījumā vienveidīgu dokumentu ievadei...

Protams, kā būs vajadzīgs!

Mērķis - lai grāmatvedis nepilda operatoru funkcijas

На спор? Найдет кучу!

Ну-ну... Ничего она не найдет. Если даже бух иногда с большим трудом что-то находит, то прога явно не умнее его. Алгоритм для проги таки составляет человек.

Чего Ты, Альбиш, ерепенишься....Сказано найдёт! -значит найдёт!! Другое дело ЧТО найдёт!!! А это уже не наша забота....Зато сможем честно грить,мол, мы ничего не знаем, что там программа сама себе понавыдумывала.....

Я представляю какой объем памяти понадобится для такой проги, которая будет все чеки сканировать. У нас их тысячи.. Это не считая всего остального.