Closed batot1 closed 3 years ago
Nagraj screencasta bo nie ogarniam co piszesz.
Przyznam szczerze nie rozumiem czego ty nie rozumiesz. Czy co to jest faktura czy może co to jest zobowiązanie bez fakturowe czy może fakt, że się nie wystawia? Doprecyzuj czego nie rozumiesz.
Powtórzę poproszę o screencasta to pomogę. Na zrzucie nie widać co po kolei jak klikasz.
Nie będzie screencasta ze względu na dane osobowe chronione a ja nie zamierzam bawić się w naukę obróbki filmu. Wyżej napisałem spep by step jak odtworzyć błąd a na załączonym screenie, gdzie widać co naciskam a na samym dole strzałeczki co otrzymuję.
Czy może ktoś u siebie sprawdzić na wersji pobranej z gita odpalonej na starej bazie LMS'a czy tak samo jak u mnie nie można wystawić faktury bo zamiast niej tworzy się zobowiązanie bezfakturowe wedle nomenklatury LMS'a "Należności beztaryfowa". Tak samo nie można zamienić "Należności beztaryfową" na fakturę co widać na wyżej załączonym screenie.
@interduo rozumiem że nie rozumiesz, więc daj się innym wypowiedzieć co rozumieją w czym problem.
Tak odtwarzana czynność u mnie działa prawidłowo. Zapewne u Ciebie występują jakieś inne dodatkowe "okoliczności". Stąd prośba o screencast.
@interduo Nic dodatkowego nie występuje.
Problem dotyczy tylko tych klientów którzy zostali przeniesieni z bazy LMS 1.11.13 w sposób opisany w wątku https://github.com/lmsgit/lms/issues/1763
Natomiast jak stworze nowego użytkownika to wystawianie faktur działa poprawnie - ale jaja.
Oto dowód:
Czyli resumując nie działa przeniesienie poprawnie z diara 1.11.13 do LMS git-26 wątek #1763.
@balot możesz sprawdzić czy problematyczny(stary) klient ma przypisaną firmę?
@balot generalnie najlepiej by było jakbyś w bazie danych w tabeli 'customers' porównał wiersze dla obu klientów, nowego i starego.
@balot możesz sprawdzić czy problematyczny(stary) klient ma przypisaną firmę?
Pewnie:
MariaDB [lms]> SELECT divisionid FROM customers where id in (425,528);
+------------+
| divisionid |
+------------+
| 1 |
| 1 |
+------------+
2 rows in set (0.00 sec)
MariaDB [lms]>
@balot generalnie najlepiej by było jakbyś w bazie danych w tabeli 'customers' porównał wiersze dla obu klientów, nowego i starego.
Porównałem ale nie wkleję tego (ochona danych osobowych) chyba że zmienię wszystkie dane tego przeniesionego klienta na fikcyjne to wtedy mogę wklejać do woli. Generalnie prawie w każdej kolumnie jest co innego u obu a nie wiem czego szukać.
Jeśli możesz przeprowadzić jeszcze raz proces aktualizacji to pomocne może być poniższe:
przed procesem aktualizacji LMS ustaw zmienną konfiguracyjną 'phpui.lang' na wartość 'pl' lub 'pl_PL' i wykonaj aktualizację.
Możliwe, że issue #1791 też jest z tym problemem powiązane.
To nie jest takie proste aby cała dotychczasowa migrację rozpocząć zupełnie od początku ponieważ nie mam snapshoot'a VPS'a - nie zakładałem że będzie aż tak źle. Nie chce mi się wierzyć, że z powodu braku ustawień w "php.ini" PL baza źle się zaktualizowała i dlatego nie wystawiają się faktury - nie widzę związku. Mam inną bazę z Diary 1.11.13, więc tu nie ma problemu, ale teraz pytanie czy mam ją wgrać do MariaDB czy downgrade do mysql i dopiero MariaDB? Sporo pracy.
Mam lepszy pomysł. Wyeksportuje Wam pozycję z bazy customers a wy możecie sprawdzić to ee w swoich pustych bazach. Zresztą sam to mogę sprawdzić importując wpis do bazy z oryginalnej git-26.
lms@lms:/var/www/lms/bin$ cat lms-payments.php |grep setlocale
lms@lms:/var/www/lms/bin$
lms@lms:/var/www/lms/lib/upgradedb$ cat * |grep setlocale
lms@lms:/var/www/lms/lib/upgradedb$
cat php code AUTHORS:
Lukasz 'Baseciq' Mozer
Michal 'DziQs' Zapalski
Radoslaw 'Warden' Antoniuk
Krzysztof 'hunter' Drewicz
Marcin 'Lexx' Krol
Aleksander 'A.L.E.C' Machniak
Tomasz 'Chilek' Chilinski
Grzegorz 'Ceho' Chwesewicz
Maciej 'Lion' Lew
Rafał 'Ravvar' Pietraszewicz
Panowie jeśli działanie skryptów php jest uzależnione od strony kodowej (wow) to czy to takie trudne zastosować w kodzie php setlocale() ?
Oto różnice w bazie customers między "działającym" a nie działającym userem.
MariaDB [lms]> SELECT moddate,creatorid,modid,pin FROM customers where id in (425,529);
+------------+-----------+-------+--------+
| moddate | creatorid | modid | pin |
+------------+-----------+-------+--------+
| 1599819256 | 6 | 1 | 743531 |
| 0 | 1 | NULL | 2818 |
+------------+-----------+-------+--------+
2 rows in set (0.00 sec)
MariaDB [lms]>
szukam dalej i testuje...
@batot1 wystarczyło napisać, że nie możesz zrobić ponownej aktualizacji. Widać, że znacznie podniosłeś poziom swojej wiedzy od ostatniego postu :)
Panowie jeśli działanie skryptów php jest uzależnione od strony kodowej (wow) to czy to takie trudne zastosować w kodzie php setlocale() ?
@batot1 widzę, że w reakcji na pomoc i próby rozwiązania Twoich problemów cały czas wylewasz swoje frustracje i dyskredytujesz LMS i jego developerów. W związku z tym jakakolwiek pomoc z mojej strony dla Ciebie nie może być kontynuowana i nie będzie. Być może reszta społeczności LMS jest gotowa znosić takie podejście z Twojej strony i będzie Ci nieść pomoc w Twojej niedoli. Powodzenia.
Nadmienię tylko to nie wina tabeli customers bo dwa identyczne wpisy o różnych id a jeden potrafi wystawiać faktury a drugi nie. Wina jest gdzie indziej. Trzeba by sprawdzić wszystkie tabele zależne od customers.
@rafalpietraszewicz Nie chcesz nie pomagaj. Nie chce wchodzić w przepychanki słowne. Zauważ że robicie z ludzi beta testerów Waszego programu. Korzyści są obustronne. Skoro git-26 to rdzeń LMS+ czyli można zakładać że problem także dotyczy wersji LMS+.
Po konsultacji z programistą jest sporo pracy aby znaleźć przyczynę tego problemu ale to możliwe. Jeśli jest jakaś prostsza metoda od sprawdzania pozostałych tabel to jestem otwarty na sugestię. Problem nie rozwiązany, migracja niemożliwa z 1.11.13 do git-26 na dzień dzisiejszy.
Najgorsze jest to że w zasadzie nic nie zmienialiśmy a klient ID=529 stworzony w GIT-26 który mógł wystawiać fakturę nagle stracił tą możliwość i teraz już nie potrafi wystawiać faktur. Czyli z jakiegoś powodu nawet nowi klienci tracą możliwość wystawiania faktur pomimo, że po stworzeniu klienta mogli wystawiać.
Serio tylko u mnie ten problem występuje czy po prostu nikt nie używa GIT-26 i nie "bawi się klientami"? Śledztwo nadal trwa...
Przyczyna znaleziona i nic nie ma wspólnego z ustawieniem php.ini. Dodanie "adresu do korespondencji" powoduje brak możliwości wystawiania faktur a po usunięciu adresu do korespondencji powoduje przywrócenie możliwości wystawiania faktur. Czysty GIT-26 na czystej bazie GIT-26 ten sam efekt występuje - potwierdzone.
Przy okazji poprawcie opis tabeli przy Tworzeniu faktury z " Należności beztaryfowe: " na " Należności bez fakturowe: ", które są o wiele bardziej poprawną formą opisująca te dokumenty.
Sorry za typ pliku ale z lenistwa nie chciało mi się kombinować ;)
https://www.screencast.com/t/T8XAAAcziOJP
pod wyżej wypisanym linkiem film z problemem
@hoktaur a widziałeś jakieś błędy w SQL lub w logach serwera www? Nie mogę tego odwzorować - ale ja mam inny silnik DB.
Nie wiem jak u kolegi @hoktaur ale u mnie jest tak:
lms@lms:~$ sudo cat /var/log/apache2/error.log
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20151012/php_mysqli.dll' - /usr/lib/php/20151012/php_mysqli.dll: cannot open shared object file: No such file or directory in Unknown on line 0
[Fri Sep 25 06:25:01.919195 2020] [mpm_prefork:notice] [pid 28207] AH00163: Apache/2.4.25 (Debian) configured -- resuming normal operations
[Fri Sep 25 06:25:01.919221 2020] [core:notice] [pid 28207] AH00094: Command line: '/usr/sbin/apache2'
lms@lms:~$
Mysqli załadowany.
root@lms:/etc/php/7.0/apache2# php -m
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
json
libxml
mbstring
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
Phar
posix
readline
Reflection
session
shmop
SimpleXML
soap
sockets
SPL
standard
sysvmsg
sysvsem
sysvshm
tokenizer
wddx
xml
xmlreader
xmlwriter
xsl
Zend OPcache
zip
zlib
[Zend Modules]
Zend OPcache
root@lms:/etc/php/7.0/apache2#
@batot1 pytam o błędy w /var/log/mysql/error.log, i czy wszystkie vhosty masz w apache2 w jednym error.log ?
nie ma żadnych swoją drogą nie są one 'wyciszone' ?
Chwilę posiedziałem i zablokowanie warunku w LMSFinanceManager.php
1929 if (empty($post_address_id)) {
1930 $invoice['invoice']['post_address_id'] = null;
1931 } else {
1932 $invoice['invoice']['post_address_id'] = $location_manager->CopyAddress($post_address_id);
1933 }
pozwala wygenerować fakturę ale oczywiście wprowadza ograniczenia
Czysty Debian bez modyfikacji czyli domyślnie logi z PHP o które pytałeś lecą tam do /var/log/apache2/error.log co widać po zawartości logów. To jest Debian testowy tylko do testowania LMS'a więc nie korzystam tu z opcji VHOST. Nie ma w katalogu apache2 innego pliku error lms git-26 od strony webowej nie generuje żadnych błędów w użytkowaniu (na chwile obecną).
lms@lms:~$ sudo ls -la /var/log/mysql.*
-rw-r----- 1 mysql adm 0 lut 6 2020 /var/log/mysql.err
-rw-r----- 1 mysql adm 0 lut 6 2020 /var/log/mysql.log
-rw-r----- 1 mysql adm 20 lip 15 2015 /var/log/mysql.log.1.gz
-rw-r----- 1 mysql adm 20 lip 14 2015 /var/log/mysql.log.2.gz
-rw-r----- 1 mysql adm 20 lip 13 2015 /var/log/mysql.log.3.gz
-rw-r----- 1 mysql adm 20 lip 12 2015 /var/log/mysql.log.4.gz
-rw-r----- 1 mysql adm 20 lip 11 2015 /var/log/mysql.log.5.gz
-rw-r----- 1 mysql adm 20 lip 10 2015 /var/log/mysql.log.6.gz
-rw-r----- 1 mysql adm 20 lip 9 2015 /var/log/mysql.log.7.gz
lms@lms:~$ sudo ls -la /var/log/apache2
razem 168
drwxr-x--- 2 root adm 4096 wrz 25 06:25 .
drwxr-xr-x 11 root root 4096 wrz 25 06:25 ..
-rw-r----- 1 root adm 0 wrz 25 06:25 access.log
-rw-r----- 1 root adm 14034 wrz 24 19:42 access.log.1
-rw-r----- 1 root adm 380 wrz 3 09:37 access.log.10.gz
-rw-r----- 1 root adm 1038 wrz 2 16:37 access.log.11.gz
-rw-r----- 1 root adm 552 wrz 1 16:09 access.log.12.gz
-rw-r----- 1 root adm 3676 sie 27 17:26 access.log.13.gz
-rw-r----- 1 root adm 278 maj 26 2015 access.log.14.gz
-rw-r----- 1 root adm 11588 wrz 22 22:15 access.log.2.gz
-rw-r----- 1 root adm 1849 wrz 22 00:20 access.log.3.gz
-rw-r----- 1 root adm 633 wrz 12 21:13 access.log.4.gz
-rw-r----- 1 root adm 14294 wrz 11 23:46 access.log.5.gz
-rw-r----- 1 root adm 8762 wrz 10 15:06 access.log.6.gz
-rw-r----- 1 root adm 2487 wrz 7 11:33 access.log.7.gz
-rw-r----- 1 root adm 5190 wrz 6 14:22 access.log.8.gz
-rw-r----- 1 root adm 930 wrz 4 11:03 access.log.9.gz
-rw-r----- 1 root adm 459 wrz 25 06:25 error.log
-rw-r----- 1 root adm 577 wrz 25 06:25 error.log.1
-rw-r----- 1 root adm 351 wrz 16 06:25 error.log.10.gz
-rw-r----- 1 root adm 350 wrz 15 06:25 error.log.11.gz
-rw-r----- 1 root adm 352 wrz 14 06:25 error.log.12.gz
-rw-r----- 1 root adm 352 wrz 13 06:25 error.log.13.gz
-rw-r----- 1 root adm 349 wrz 12 06:25 error.log.14.gz
-rw-r----- 1 root adm 353 wrz 24 06:25 error.log.2.gz
-rw-r----- 1 root adm 350 wrz 23 06:25 error.log.3.gz
-rw-r----- 1 root adm 350 wrz 22 06:25 error.log.4.gz
-rw-r----- 1 root adm 349 wrz 21 06:25 error.log.5.gz
-rw-r----- 1 root adm 350 wrz 20 06:25 error.log.6.gz
-rw-r----- 1 root adm 352 wrz 19 06:25 error.log.7.gz
-rw-r----- 1 root adm 352 wrz 18 06:25 error.log.8.gz
-rw-r----- 1 root adm 349 wrz 17 06:25 error.log.9.gz
-rw-r----- 1 root adm 0 maj 15 2015 other_vhosts_access.log
lms@lms:~$
@hoktaur a widziałeś jakieś błędy w SQL lub w logach serwera www? Nie mogę tego odwzorować - ale ja mam inny silnik DB.
To jakiś problem postawić VPS'a z MariąDB na pokładzie? Nawet VPS'a nie trzeba wystarczy jedna zmiana w lms.ini oraz instalacja MariaDB aby odwzorować warunki. Jak nie chcecie rozwijać LMS'a pod MariaDB to udostępnijcie skrypt do przejścia na Posgres'a a to pewnie wszyscy się przesiądą a tam z przymusu wszyscy zostaną przy MariaDB.
Migrację możesz zrobić za pomocą narzędzia pg_loader nic nie trzeba udostępniać.
@batot1 należności beztaryfowe i bezfakturowe to co innego. Beztaryfowe wystawione ręcznie (nie za pomocą lms-payments.php). Bez fakturowe mogą być już wystawione za pomocą w/w skryptu.
PS. @batot1 to również Twój program skoro go używasz ;-)
Jeśli o Twój problem chodzi - SOA#1.
@batot1 należności beztaryfowe i bezfakturowe to co innego. Beztaryfowe wystawione ręcznie (nie za pomocą lms-payments.php). Bez fakturowe mogą być już wystawione za pomocą w/w skryptu.
Niekoniecznie bo można taryfowe zobowiązania (abonamentowe) wystawić ręcznie a bezfakturowym zobowiązaniem będzie zawsze (bo nie ma faktury). Inaczej mówiąc mogą tam się znaleźć taryfowe zobowiązania ale na pewno nigdy nie mogą się tam znaleźć bezfakturowe. Niby mały lapsus słowny dla Was informatyków ale obecny opis myli kogoś kto się zna na księgowości. Dla programisty to zapewne jeden pieron czy beztaryfowe czy bezfkatutrowe. Zapytaj o zdanie ludzi co znają się na księgowości a zobaczysz co oni na to. Nie chcecie zmieniać nie zmieniajcie. W starym LMS (diara) nie ma takich mylnych opisów ;)
Jeśli o Twój problem chodzi - SOA#1.
Nie sądzę skoro zupełnie inny użytkownik nagrał ci nawet że u siebie ma identyczny problem.
Update z git 01-10-2020 + pomniejsze ręcznie do dzisiaj Fakrury można wystawiać, ale GTU nie widnieje na fakturze. Jest identyczny problem z wystawianiem faktur lorygujących: Brak faktury korygującej.(dokumentu do wydruku). Jak gdyby było to zobowązanie bezfakturowe
Tam jest coś w kodzie namotane mocniej z tymi fakturami plik: LMSFinanceManager.php może kiedyś to poprawią.
@mocakow a u ciebie wystawia się faktura ręcznie jak masz wpisany adres do korespondencji u abonenta czyli łącznie 2 adresy? Jaka baza SQL? jaka wersja. Pytam bo nam nie działa to (wyżej nawet filmik masz).
Jeśli o Twój problem chodzi - SOA#1.
Nie sądzę skoro zupełnie inny użytkownik nagrał ci nawet że u siebie ma identyczny problem.
Nie rozumiem dlaczego nie wierzysz na słowo:
@interduo czyli u Ciebie działa? U mnie oczywiście również.
@chilek nagrałem screencasta - #SOA1
Co do GTU - nie widzę również GTU - ale to pewnie wynika z tego, że w taryfie nie mam wybranej kategorii podatkowej.
Po wybraniu w taryfie kategorii podatkowej - faktycznie nie pojawia się na fakturach - to mogę potwierdzić.
I znalazłem jeszcze jeden drobny mankament - przy edycji taryfy pole "stawka podatkowa" świeci zawsze na czerwono mimo dokonanego wyboru.
invoices.show_tax_category
Typ: Wartość logiczna.
Wartość domyślna: false
Opis: Ustawienie true powoduje włącznie na fakturach prezentacji dodatkowej kolumny GTU używanej na potrzeby JPK. Nawet jeśli włączymy prezentację tej kolumny, zostanie ona ukryta w sytuacji, gdy żadna pozycja faktury nie posiada zdefiniowanej właściwości GTU.
Dostępność: od 26.0, 25.12, 24.38
Nie rozumiem dlaczego nie wierzysz na słowo:
Czemu wy nie wierzycie na słowo że nie działa? Mam tak samo jak u niego - zobacz: https://www.screencast.com/t/T8XAAAcziOJP
@chilek a dlaczego wartość domyślna to false?
Czemu wy nie wierzycie na słowo że nie działa? Mam tak samo jak u niego - zobacz:
@batot1 dlaczego od początku trzymasz się kurczowo głupiego pomysłu używania MySQL na potrzeby LMS? Wyczuwam jakieś skłonności sado-maso...
ooo widzę że właśnie zmieniłeś :)
@chilek a dlaczego wartość domyślna to false?
false miało sens, ale niestety większość ludzi nie czyta jakiejkolwiek dokumentacji. Dlaczego miało sens? Bo kategoria podatkowa/GTU ma niski sens zagranicą ...
Kolumna się nie pokazuje gdy nie ma ustawionej kategorii podatkowej w pozycji FV. 10x za commita.' To zostało jeszcze świecenie pola stawka podatkowa w formularzu edycji FV.
Tam jest coś w kodzie namotane mocniej z tymi fakturami plik: LMSFinanceManager.php może kiedyś to poprawią.
@mocakow a u ciebie wystawia się faktura ręcznie jak masz wpisany adres do korespondencji u abonenta czyli łącznie 2 adresy? Jaka baza SQL? jaka wersja. Pytam bo nam nie działa to (wyżej nawet filmik masz).
invoices.show_tax_category
Typ: Wartość logiczna.
Wartość domyślna: false
Opis: Ustawienie true powoduje włącznie na fakturach prezentacji dodatkowej kolumny GTU używanej na potrzeby JPK. Nawet jeśli włączymy prezentację tej kolumny, zostanie ona ukryta w sytuacji, gdy żadna pozycja faktury nie posiada zdefiniowanej właściwości GTU.
Dostępność: od 26.0, 25.12, 24.38
Ustawienie zmiennej zadzialalo. okazuje się ze problem korekt dotyczy faktur wystawionych przed 4.10.2020 ? Byla poprawka. Coś jest nie tak z flagą TP w VAT7M. Flaga nie ustawiona w formatce edycji customers a do pliku VAT7M dodaje TP 1 muszę updatować flags z 4 na 0 w tabeli documents. dla paru kientów.
Na fakturze brak : "Kod pocedury podatkowej: " Może jest jakaś "magiczna wartość w invoices.xxxxxx ?
Tam jest coś w kodzie namotane mocniej z tymi fakturami plik: LMSFinanceManager.php może kiedyś to poprawią.
@mocakow a u ciebie wystawia się faktura ręcznie jak masz wpisany adres do korespondencji u abonenta czyli łącznie 2 adresy? Jaka baza SQL? jaka wersja. Pytam bo nam nie działa to (wyżej nawet filmik mas
Tam jest coś w kodzie namotane mocniej z tymi fakturami plik: LMSFinanceManager.php może kiedyś to poprawią.
@mocakow a u ciebie wystawia się faktura ręcznie jak masz wpisany adres do korespondencji u abonenta czyli łącznie 2 adresy? Jaka baza SQL? jaka wersja. Pytam bo nam nie działa to (wyżej nawet filmik masz).
Masz uprawnienia do katalogu lms (chown -R) . Rozwiązuje wiele problemów z dokumentami (zapis).
@mocakow Widzę nie czytasz wcześniejszych wypowiedzi ani filmiku nie widziałeś. Jak byś czytał wiedział że zmiana pola "do korespondencji" decyduje o tym czy ma się wystawić faktura czy nie ma. Tak więc to nie wina uprawnień. Wskazaliśmy nawet plik w którym jest błąd w kodzie: "LMSFinanceManager.php", skąd więc pomysł braku uprawnień skoro raz się wystawiają a raz nie wystawiają w zależności od pola adresat?
lms@lms:/var/www/html$ ls -la lms-git26
razem 312
drwxrwxr-x 26 www-data www-data 4096 wrz 2 10:21 .
drwxrwxr-x 8 root lms 4096 wrz 4 10:02 ..
drwxrwxr-x 2 www-data www-data 4096 wrz 2 09:01 backups
drwxrwxr-x 3 www-data www-data 4096 wrz 10 09:26 bin
-rw-rw-r-- 1 www-data www-data 4659 wrz 2 09:01 composer.json
-rw-rw-r-- 1 www-data www-data 112596 wrz 2 10:21 composer.lock
drwxrwxr-x 21 www-data www-data 4096 wrz 2 09:01 contrib
drwxrwxr-x 7 www-data www-data 4096 wrz 2 09:01 css
drwxrwxr-x 7 www-data www-data 4096 wrz 2 09:01 daemon
drwxrwxr-x 4 www-data www-data 4096 wrz 2 09:01 debian
drwxrwxr-x 2 www-data www-data 4096 wrz 2 09:01 devel
drwxrwxr-x 4 www-data www-data 4096 wrz 2 09:01 doc
drwxrwxr-x 5 www-data www-data 4096 wrz 22 20:34 documents
drwxrwxr-x 8 www-data www-data 4096 wrz 2 09:01 .git
-rw-rw-r-- 1 www-data www-data 171 wrz 2 09:01 .gitattributes
drwxrwxr-x 3 www-data www-data 4096 wrz 2 09:01 .github
-rw-rw-r-- 1 www-data www-data 416 wrz 2 09:01 .gitignore
-rw-rw-r-- 1 www-data www-data 55 wrz 2 09:01 .htaccess
drwxrwxr-x 3 www-data www-data 12288 wrz 2 09:01 img
-rw-rw-r-- 1 www-data www-data 21251 wrz 2 09:01 index.php
drwxrwxr-x 9 www-data www-data 4096 wrz 2 09:01 js
-rw-rw-r-- 1 www-data www-data 288 wrz 2 09:01 .jshintignore
-rw-rw-r-- 1 www-data www-data 81 wrz 2 09:01 .jshintrc
drwxrwxr-x 17 www-data www-data 4096 wrz 22 20:46 lib
drwxrwxr-x 7 www-data www-data 20480 wrz 22 22:16 modules
drwxrwxr-x 2 www-data www-data 4096 wrz 2 09:01 nbproject
-rw-rw-r-- 1 www-data www-data 653 wrz 2 09:01 phpcs2.xml
-rw-rw-r-- 1 www-data www-data 692 wrz 2 09:01 phpcs3.xml
-rw-rw-r-- 1 www-data www-data 163 wrz 2 09:01 phpunit.xml
drwxrwxr-x 3 www-data www-data 4096 wrz 2 09:01 plugins
-rw-rw-r-- 1 www-data www-data 973 wrz 2 09:01 README.md
drwxrwxr-x 2 www-data www-data 4096 wrz 2 09:01 sample
drwxrwxr-x 3 www-data www-data 4096 wrz 2 09:01 templates
drwxrwxr-x 2 www-data www-data 4096 wrz 22 21:08 templates_c
drwxrwxr-x 3 www-data www-data 4096 wrz 2 09:01 tests
-rw-rw-r-- 1 www-data www-data 2151 wrz 2 09:01 .travis.yml
drwxrwxr-x 7 www-data www-data 4096 wrz 2 09:01 userpanel
drwxrwxr-x 39 www-data www-data 4096 wrz 2 10:21 vendor
drwxrwxr-x 2 www-data www-data 4096 wrz 2 09:01 voipcalls
lms@lms:/var/www/html$
lms@lms:/var/www/html/lms-git26$ ls -la documents/
razem 24
drwxrwxr-x 5 www-data www-data 4096 wrz 22 20:34 .
drwxrwxr-x 26 www-data www-data 4096 wrz 2 10:21 ..
drwx------ 2 www-data www-data 4096 wrz 22 20:34 84
drwx------ 2 www-data www-data 4096 wrz 6 10:29 9d
-rwxrwxr-x 1 www-data www-data 31 wrz 2 09:01 .htaccess
drwxrwxr-x 8 www-data www-data 4096 wrz 6 10:29 templates
lms@lms:/var/www/html/lms-git26$
@batot1 widziałeś mój filmik? Wpisałem adres do korespondencji - faktura się wystawia. Jeszcze raz powtórzę - SOA#1
@interduo To nie jest SOA jeden skoro problem jest powtarzalny i bardzo łatwy do odtworzenia bo występuje nawet na pustej bazie nie tylko u mnie.
Wysłałem Ci filmik, że u mnie nie działa. Proszę obejrz go i pokieruj mnie jak zrobić by wystąpił u mnie.
Jeśli u mnie nie wystąpi (a nie występuje u mnie na 3 instancjach i u @chilek) nie dasz możliwości nam Ci pomóc. I proszę nie mądrzyj się tylko postępuj wg poleceń.
@interduo
Po pierwsze pewnie macie inną wersję gita, po drugie pewnie macie posgresa anie MariaDB po trzecie inny system więc jak by nie było sporo inny system. Na MariaDB z Debianem dwa niezależne systemy i objaw występuje. Skoro u Was działa i nie ma błędu w programie pomimo że wskazujemy Ci nawet gdzie jest błąd to powiedz co zrobić aby działało skoro niby to nasza wina?
Wstępna weryfikacja Wchodzę na klienta i naciskam "nowy dokument: faktura" Tworzę i wychodzi mi zobowiązanie bez fakturowe. Próbuję z opcji Finanse->Nowa faktura .... Wynik ten sam zobowiązanie bez fakturowe. Nadmienię że nawet nie da się tego zobowiązania zamienić na fakturę.
Środowisko - prosimy o uzupełnienie następującej informacji: