Теоретические размышления о реализации сторно в ERP системе

[mazzy]

Цитата:

Сообщение от Lemming

и не заставлять пользователей получать инфаркт (как в аксапте ), когда они допустили ошибку и разнесли документ с ошибками?

Тут дело не в системе.

ключевой вопрос - допустимы ли исправления уже проведенного документа в многопользовательской системе?

аналог разноски IRL - поставить подпись/печать под документом и отправить этот документ другим людям, которые будут принимать свои решения и подписывать свои документы на основании данного.

вопрос - можно ли сказать ОЙ забрать документ обратно и исправить его? технически можно конечно. Но огранизационно - нет. Вплоть до инфарктов Поскольку на основании подписанного документа другие люди уже поработали и что-то сделали.

ERP система только многократно ускоряет этот процесс.

[Lemming]

Цитата:

Сообщение от mazzy

Тут дело не в системе.

Мысль понятна, но практика подсказывает...вот я для этого и создал тему, что бы поразмышлять над тем, как лучше всего было бы спроектировать, что бы и "И волки сыты и овцы целы" были!?

Цитата:

Сообщение от mazzy

аналог разноски IRL - поставить подпись/печать под документом и отправить этот документ другим людям, которые будут принимать свои решения и подписывать свои документы на основании данного

Во основе моего вопроса лежит еще мысль о том, что да, на западе они спокойно живут со сторно, а вот на просторах СНГ (кстати, интересно как в Индии и Азии), существует проблема, которая особенно остро ощущается при смешивании Российского пользователя-бухгалтера и западной ERP системы.

[mazzy]

Цитата:

Сообщение от Lemming

на западе они спокойно живут со сторно

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

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

[Lemming]

Цитата:

Сообщение от mazzy

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

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

[mazzy]

Цитата:

Сообщение от Lemming

Это наталкивает на мысль о том, что может быть дело и не в сторно, а в том как нам сделать разноску удобней?

да, добавлять бизнес-проверки.
то что постоянно делают во время внедрений.

да, стандартный функционал аксапты слабый в этой области.

Цитата:

Сообщение от Lemming

Я не помню стандарт это или модификация: предварительный просмотр проводок, он отчасти спасал, но я его только в журналах ГК видел.

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

Цитата:

Сообщение от Lemming

Потому что, получается, что подход 1С - это жизненная необходимость, но он ведь тоже работает так себе.

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

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

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

1Су очень тяжело вводить функционал, который не решает проблемы их целевой аудитории. Еще сложнее вводить функционал, который противодействует интересам их целевой аудитории. Хотя процесс идет, конечно.

[mazzy]

Цитата:

Сообщение от Lemming

а вот на просторах СНГ (кстати, интересно как в Индии и Азии)

у них примерно также как и у нас.

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

собственно очень похоже, что чем беднее страна, тем больше желания зарегулировать бузинес.

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

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

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

Но меня удивило даже не два статуса отмены, а то что регулирующие органы в бразилии как-то одобряют на уровне каждой сделки!

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