Społeczność Comarch ERP | Użytkownicy Klienci Partnerzy Comarch

Profil użytkownika

avatar

Marcin Liszewski

968 pkt
 
partner
2 Podziękowań
83 100%

8 pytań

47 odpowiedzi

427 96%

63 pomysłów

101 komentarzy

Aktywność

  • Wartościowy użytkownik
  • Wysoko notowany
  • Lider rankingu
  • Aktywny użytkownik
  • Pomysłodawca
  • Uczynny użytkownik
  • Znawca tematu
  • Specjalista kategorii Chmura
  • Specjalista kategori ERP Altum
  • Specjalista kategorii ERP Optima
  • Specjalista kategorii ERP XL
  • Specjalista kategorii ERP XT
  • Specjalista kategorii ERP esklep
  • Specjalista kategorii ERP mobile
  • Specjalista kategorii ERP Produkcja
  • Specjalista kategorii IBARD
  • Specjalista kategorii wszystko.pl
  • Specjalista kategorii ERP Klasyka
  • Specjalista kategorii ERP iKsięgowośc 24
  • Specjalista kategorii ERP Retail
  • Specjalista kategorii Workflow
  • Specjalista kategorii Techniczne
  • Specjalista kategorii Handel
  • Specjalista kategorii Logistyka
  • Specjalista kategorii Księgowość
  • Specjalista kategorii BI
  • Specjalista kategorii Kadry płace

Rankingi

Miejsce W tym
miesiącu
Punktów
Ranking główny 39 2 968 pkt
W tym miesiącu 2 2 33 pkt
Pytania i odpowiedzi 104 15 206 pkt
Pomysły i komentarze 22 1 611 pkt
Najbardziej pomocni 125 114 -

Wpisy użytkownika

User Avatar
partner
Marcin Liszewski
968 pkt
8 pytań
47 odpowiedzi
63 pomysłów
101 komentarzy
510 97%
Marcin Liszewski napisał/a o
Księgowość
Księgowość pomysłów: 493 | odpowiedzi: 4889

Księgowość

Marcin LiszewskiGrzegorz MączkaZbigniew RymarczykPIEKARNIA Jacek SadowskiPiotr ZborowskiSylwia Krzemińska-PańczykAgnieszka Bogacz
Comarch ERP Optima
Comarch ERP Optima pomysłów: 1460 | odpowiedzi: 19321

Optima

Piotr ZarzyckiJacek RudnickiMarcin LiszewskiStanisław PachaczDawid BłędowskiZbigniew RymarczykPIEKARNIA Paweł Rogoz

Poprawić mechanizm liczenia kolejnych korekt JPK

Zaktualizowano 3 d. temu

Kolejne echa problemów z wysyłką JPK za lipiec.

Mam obecnie w bazie pierwszy JPK_VAT za lipiec z błędem przetwarzania. Następnie drugi JPK_VAT za tenże lipiec (ale nie jako korekta, tylko pierwszorazowy) wysłany i przyjęty.

Teraz chcę zrobić korektę ww. i automatycznie nadaje mi się nr 2. A to powinien być nr 1. Czyli O! liczy nr korekty w odniesieniu do pierwszego pliku, a nie w odniesieniu do pierwszej korekty pliku.

Sugestia: numeracja korekt powinna być liczona z pominięciem plików, które mają status typu "Błąd przetwarzania" i/lub nr korekty liczyć w odniesieniu do poprzedniej prawidłowo przetworzonej korekty.

Oczywiście, możnaby skasować błędnie przetworzony plik JPK, ale dla bezpieczeństwa i ochrony przed ewentualnymi roszczeniami ze strony kogokolwiek - nie zrobię tego. Dopóki grozi mi potencjalna odpowiedzialność za nie złożenie JPK_VAT w terminie, to pomimo komunikatów MF o "nie wyciąganiu konsekwencji", wolę zachować ostrożność. (Zawuażmy, że "nie wyciąganie konsekwencji" ma dotyczyć JPK_VAT za lipiec, a mam również w BR kilka przypadków, że w pechowym tygodniu sierpnia nie przeszły mi korekty za inne niż lipiec 2019 miesiące - więc tych komunikat abolicyjny nie obejmuje).

User Avatar
partner
Marcin Liszewski
968 pkt
8 pytań
47 odpowiedzi
63 pomysłów
101 komentarzy
510 97%
Marcin Liszewski napisał/a o
Księgowość
Księgowość pomysłów: 493 | odpowiedzi: 4889

Księgowość

Marcin LiszewskiGrzegorz MączkaZbigniew RymarczykPIEKARNIA Jacek SadowskiPiotr ZborowskiSylwia Krzemińska-PańczykAgnieszka Bogacz
Comarch ERP Optima
Comarch ERP Optima pomysłów: 1460 | odpowiedzi: 19321

Optima

Piotr ZarzyckiJacek RudnickiMarcin LiszewskiStanisław PachaczDawid BłędowskiZbigniew RymarczykPIEKARNIA Paweł Rogoz

Odblokowanie pola kategorii "Księguj w koszty" w KH

Zaktualizowano 6 d. temu

Ukrycie tego pola w module KH jest nieuzasadnionym utrudnieniem pracy.

W przypadku kosztów rozliczanych wg stałego współczynnika 20% albo 75%,  można posłużyć się zbiorczą kategorią dla tych kosztów (np. jedna dla paliwa do wszystkich sam. osobowych, jedna do części zamiennych, jedna dla opłat parkingowych itd.).

Jednak w przypadku księgowania opłat leasingowych dotyczących sam. osobowych, gdzie współczynnik zaliczenia w koszty może wynieść teoretycznie od 1 do 99% (w zależności od osobistych przekonań księgowego z miejscami po przecinku lub bez) i dla każdego z kilku(dziesięciu/-set...) samochodów w firmie może być inny. Najprostszym i najszybszym rozwiązaniem byłoby posłużenie się właśnie wskaźnikiem % ustalanym na poziomie kategorii przypisanej do konkretnego samochodu, i pobieranym jednorazowo w jednym (lub w zależności od przyjętej konstrukcji - dwóch) wierszu schematu.

Tymczasem ukrycie tego wskaźnika przed użytkownikiem KH, zmusza do dopisywania osobnego wiersza w schemacie dla każdego samochodu osobowego w leasingu, który powiąże konkretny współczynnik % z kategorią przypisaną do samochodu. Rozwiązanie to niepotrzebnie komplikuje i powiększa schemat, czyni go mniej przejrzystym, jak również niepotrzebnie spowalnia i tak nie będący demonem szybkości system dodając dodatkowe, niepotrzebne operacje.
I tak schemat księgowania z rejestru zakupów VAT, który dotychczas miał kilka wierszy, obecnie może mieć kilka wierszy PLUS kilka(dziesiąt/-set...) kolejnych po 1-2 wiersze dla każdego samochodu osobowego. Po co?

Jeśli ktoś nie chce mieć zbyt trudnych definicji schematów, to pozostaje ręczna predekretacja ze wsparciem kalkulatora. A wystarczyłoby odblokować w interfejsie jedno pole, które i tak jest w bazie.

User Avatar
partner
Marcin Liszewski
968 pkt
8 pytań
47 odpowiedzi
63 pomysłów
101 komentarzy
510 97%
Marcin Liszewski napisał/a o
Płace i Kadry
Płace i Kadry pomysłów: 242 | odpowiedzi: 3827

Marcin LiszewskiPiotr SzokaMonika KalaWojciech PawełkaRafał KurabiowskiEstera OrzeszynaAgnieszka WalczakAleksandra Dudzic
Ogólne
Ogólne pomysłów: 145 | odpowiedzi: 2799

Jacek RudnickiMarcin LiszewskiDawid BłędowskiTadeusz SasnalPiotr BartosiakPiotr ZborowskiPaweł BrzostowskiDominik Wajda
Comarch ERP Optima
Comarch ERP Optima pomysłów: 1460 | odpowiedzi: 19321

Optima

Piotr ZarzyckiJacek RudnickiMarcin LiszewskiStanisław PachaczDawid BłędowskiZbigniew RymarczykPIEKARNIA Paweł Rogoz

Wbudowany słownik (chociaż) powiatów

Zaktualizowano 8 d. temu

Ilość i nazwy powiatów w Polsce zachowują się w dość stabilnie. Dlaczego więc O! nie ma wbudowanego słownika powiatów, tak jak to jest z województwami?

Funkcjonalnosć ma szczególne znaczenie w przypadku modułu kadrowego, gdzie często od pracowników/zleceniobiorców w kwestionariuszu otrzymuje się nazwy powiatów w formie nie do końca prawidłowej np.

- taka sama nazwa dla miasta na prawach powiatu jak dla powiatu ziemskiego mającego siedzibę w tym mieście (np. Częstochowa mnpp to co innego niż powiat częstochowski, a mieszkańcy i jednego i drugiego jako powiat piszą nomen omen najczęściej po prostu "Częstochowa")

- nieoczywista forma nazwy powiatu, a tych jest całkiem sporo (nazwy dwuczłonowe dla siedziby powiatu w miejscowości o nazwie jednoczłonowej np. powiat bieruńsko-lędziński z siedzibą w Bieruniu, albo odwrotnie nazwy jednoczłonowe dla powiatu z siedzibą w mieście o nazwie dwułczonowej np. powiat ostrowski z siedzibą w Ostrowie Wielkopolskim, albo Ostrowi Mazowieckiej, czy po prostu nieoczywiste dla osoby z "drugiego końca mapy" formy jak np. powiat kościerski, a nie kościerzyński, powiat bielski a nie bielskobialski....).

Oczywiście, nie są to błędy, za które (póki co) grozi osadzenie w twierdzy, ale lepiej mieć niż nie mieć porządek w bazie, bez ww. rozbieżnosci czy zwykłych literówek.

Oczywiście możnaby chyba iść krok dalej i listę powiatów podpiąć jako drzewo pod odpowiednimi województwami. Bardzo przyspieszyłoby to pracę w dużych jednostkach. A co dopiero, gdyby pod powiaty podpiąć jeszcze gminy... to już byłoby szaleństwo ergonomii.