Przetwarzanie arkuszy kalkulacyjnych

Cześć,

Istnieją pliki utworzone za pomocą MS Excel, których celem jest wyliczanie jakiś wartości na podstawie danych wejściowych. Mogą zawierać nie tylko zwykłe proste formuły ale także bardziej zaawansowane skrypty.

Chciałbym mieć możliwość otwierania tego typu plików, wprowadzania do nich danych wejściowych i pobierania danych wyjściowych. Szukam więc odpowiedniego sposobu żeby to zrobić przy czym:

1. Chciałbym aby rozwiązanie było możliwe do zrealizowania za pomocą .NET Core i działało na Linuxie (nie jest to twarde wymaganie, może też działać na Windowsie i może nie być napisane w .NET Core)

2. Chciałbym żeby rozwiązanie nie wymagało zainstalowanego Excela na maszynie, która przetwarza powyższe pliki Excel-a.

3. Biblioteka powinna być darmowa do celów komercyjnych.

Znacie coś godnego polecenia?

Rynek libek excellowych w .NET jest specyficzny.
A to jedna nie umie starszego xls, a to druga nowszego xlsx, a to - jak zauważasz - opiera się na istnieniu Excella

Wylądowaliśmy na NPOI, która jest przeniesieniem uznanej javowskiej POI, choc tam też jest jakiś konflikt u twórców / fork / coś podobnego.

Emisja komórek z liczbami / stringami, emisja prostych wyrażeń - jest OK.
Dobra kompatybilność z oboma formatami Excella i OO.

Natomiast nie wiem, jakie znaczenie słowne przykładasz do detali "przetwarzania arkuszy excell". Nie wyobrażam sobie trwałej koegzystencji oprogramowania "dużego" na arkuszach w centrum systemu - dla mnie to to łyknąc obce dane na wejściu, albo wypluć na wyjściu dla obcych zastosowań, i tyle

tk napisał(a):

Mogą zawierać nie tylko ... ale także bardziej zaawansowane skrypty.

lekko byłbym przestraszony ... trochę bardziej niż lekko

Na Windowsa jest biblioteka Microsoft.Office.Interop.Excel, która powinna pozwalać na takie rzeczy, z tego co pamiętam było nieprzenośne na inne platformy i wymagało zainstalowania pakietu Office, więc nie było za darmo.

Edit: Można by spróbować zrobić np. z użyciem API Google Sheets.

Nie lepiej to przepisać na jakieś sensownego rozwiązanie, a nie bawić się w odpalanie formuł z excel? Napisz jeszcze jak duże są te pliki. W jakiej postaci masz dane wejściowe. I dlaczego tak chcesz to robić?

Chcesz zmienić plik wejściowy, odpalić całą logikę formuł excela i pobrać dane wyjściowe - dla mnie logiczne jest że to będzie wymagało zainstalowanego excela na komputerze. Inaczej biblioteka musiałaby implementować praktycznie całą logikę excela i być z nim w 100% zgodna. Wątpię czy coś takiego istnieje. Jedynym rozwiązaniem wydaje mi się zainstalowany excel i użycie wyżej wymienionego Office.Interop.

Ewentualnie możesz użyć arkuszy online i jakiegoś API - może to być wyżej sugerowane google sheets, ale microsoft też wystawia jakieś API do excela online: https://learn.microsoft.com/en-us/sharepoint/dev/general-development/how-to-set-values-of-ranges
Wydaje mi się to fajnym rozwiązaniem bo będzie w pełni kompatybilne z excelem, wymaga tylko jednej licencji i jest cross platform, ale korzysta z zewnętrznej usługi i potrzebuje pracy online

Microsoft.Office.Interop jest IMHO najlepsze do tych zastosowań, ale jeśli chcesz odpalać skrypty, to nie ma szans, żeby ci to zadziałało bez zainstalowanego Office'a. Zastanów się nad tym - co ma odpalić skrypt na tych danych? Potrzebne jest środowisko do wykonania kodu, tego nie przeskoczysz.

ZrobieDobrze napisał(a):

Rynek libek excellowych w .NET jest specyficzny.
A to jedna nie umie starszego xls, a to druga nowszego xlsx, a to - jak zauważasz - opiera się na istnieniu Excella

Spodziewałem się tego typu problemów :)

Wylądowaliśmy na NPOI, która jest przeniesieniem uznanej javowskiej POI

Z tego co się dowiedziałem mogą być problemy ze skryptami w POI. Mimo wszystko dzięki za informację.

Nie wyobrażam sobie trwałej koegzystencji oprogramowania "dużego" na arkuszach w centrum systemu.

Chodzi raczej o niewielki system spełniający kilka wymagań, który z założenia miałby być używany przez niewielką liczbę użytkowników.

tk napisał(a):

Mogą zawierać nie tylko ... ale także bardziej zaawansowane skrypty.

lekko byłbym przestraszony ... trochę bardziej niż lekko

Mam podobne obawy - z tego powodu nie wiem czy w ogóle się za to brać. Na chwilę obecną nie podjąłem decyzji. Być może oleje sprawę i nie będę tego realizował.

Generalnie najbardziej obawiam się tego, że pliki Excela mogą się zmieniać i może dojść do sytuacji, w której wszystko działa na danej libce a później może przestać jak ktoś np. zmieni skrypt w Excelu.

S4t napisał(a):

Nie lepiej to przepisać na jakieś sensownego rozwiązanie a ajie bawić się w odpalanie formuł z excel? Napisz jeszcze jak duże są te pliki. W jakiej postaci masz dane wejściowe. I dlaczego tak chcesz to robić?

Byłoby lepiej to przepisać gdyby nie fakt, że pliki Excela są dostarczane od podmiotów zewnętrznych i co jakiś czas aktualizowane. Jeżeli przeanalizuje te wszystkie skrypty i przepisze to na normalny kod w C# to później ni z gruszki ni z pietruszki mogę dostać nowe pliki Excel-a, które obliczają mniej więcej to samo w nieco inny sposób. Wtedy będę musiał analizować ponownie te wszystkie pliki. Podczas przepisywania skryptów na "sensowne rozwiązanie" można też czasem popełnić błąd, który nie zawsze wyjdzie od razu - np. przepisany kod może działać w 99% przypadkach poprawnie i nie działać w 1% przypadków szczególnych.

Pliki są raczej niewielkie jeżeli chodzi o liczbę wierszy. Nie mam ich teraz przed sobą ale myślę, że nie zawierają więcej niż 100 wierszy (mogą zwierać kilka kilkanaście arkuszy w jednym pliku). Dane wejściowe to głównie pola tekstowe / liczbowe oraz coś na wzór kontrolek "combo box" / "select".

S4t napisał(a):

Nie lepiej to przepisać na jakieś sensownego rozwiązanie a ajie bawić się w odpalanie formuł z excel? Napisz jeszcze jak duże są te pliki. W jakiej postaci masz dane wejściowe. I dlaczego tak chcesz to robić?

Byłoby lepiej to przepisać gdyby nie fakt, że pliki Excela są dostarczane od podmiotów zewnętrznych i co jakiś czas aktualizowane. Jeżeli przeanalizuje te wszystkie skrypty i przepisze to na normalny k
od w C# to później ni z gruszki ni z pietruszki mogę dostać nowe pliki Excel-a, które obliczają mniej więcej to samo w nieco inny sposób. Wtedy będę musiał analizować ponownie te wszystkie pliki.

No to niech nie wpisują w excle tylko niech wypełniają w aplikacji. Albo niech dostarczają dane w CSV i importujecie te CSV

Podczas przepisywania skryptów na "sensowne rozwiązanie" można też czasem popełnić błąd, który nie zawsze wyjdzie od razu - np. przepisany kod może działać w 99% przypadkach poprawnie i nie działać w 1% przypadków szczególnych.

No ale jak ktoś się pomyli w Excelu to też tak będzie.

Pliki są raczej niewielkie jeżeli chodzi o liczbę wierszy. Nie mam ich teraz przed sobą ale myślę, że nie zawierają więcej niż 100 wierszy (mogą zwierać kilka kilkanaście arkuszy w jednym pliku). Dane wejściowe to głównie pola tekstowe / liczbowe oraz coś na wzór kontrolek "combo box" / "select".

Ale jak ci zmienia pliki - np dołożą kolejne kolumny to twój wypełniacz też się wykrzaczy.

Moim zdaniem próbujesz jakiś problem rozwiązać w bardzo dziwny sposób, ale nie mówisz co to za problem.

@tk:

A jaki to case biznesowy?
Cenniki / katalogi ?
Sprawozdania z zawartych polis?
Kosztorysy budów?
Sprawozdania z "wykonu" czegoś ?

Kontynuując wyżej komentarz: prawie zawsze gdzie widziałem (tzw. exellowe ERP-y) , to ma geny kogoś, kto z przypadku został rozbijaczem i utrwalaczem, a nigdy nie był przygotowany do przemyślenia choćby układu danych *), układy relacyjne mu ani nie świtały **)

*) szczyl stażysta dawno temu, na opłatku czy czymś podobnym poznałem emeryta z tego zakładu, człowiek z "genami" bismarkowskiej czy austriackiej administracji (o jedno pokolenie, wiec miał dobrych "seniorów") - był jedynym który rozumiał co ja stażysta na komputerze robię. Działy , wydziały, podziały, indeksy do kartoteki głównej (i gdzie jest ta głowna, a co główną nie jest) itd ... nie rozumieli tego jego młodsi koledzy

Wiec pytanie: kim się czujesz jak koder - programista - projektant baz itd. Klikaczem kodu, czy współtwórcą obiegów dokumentów / struktur kartotek.

**) np dobry księgowy, również technologii papierowej, wie, że jeśli za rok będzie chciał "coś", to musi ustawić organizację danych (zapisów) "tak"

tk napisał(a):

Dane wejściowe to głównie pola tekstowe / liczbowe oraz coś na wzór kontrolek "combo box" / "select".

Tak poza centrum problemu: jednym z syfów excelo-ERPmanii jest nie tylko zmienność, ale wysadzenie w powietrze naszych "odwiecznych" zasad "trójpodziału władzy": oddzielenia danych / prezentacji danych / kodu. Nie może się to być bez poniesienia konsekwencji
Najllepsi z elektrodowych programistów (dla mnie elektrodowy programista to programista excella - jeśli nie kopier kodów arduino) potrafią trzymać kod w innym pliku niż dane - czego nie potrafią twoi dostawcy. Jest to rozsądne.

S4t napisał(a):

No to niech nie wpisują w excle tylko niech wypełniają w aplikacji. Albo niech dostarczają dane w CSV i importujecie te CSV

Nie mogą dostarczyć danych w CSV ponieważ dane CSV nie są interaktywne. Te pliki Excela to bardziej coś w rodzaju kalkulatorów. Ich główny cel to obliczenia.

Z racji różnych nieporozumień postanowiłem nieco bardziej wyjaśnić istotę problemu w kontekście domeny

1. Jest sobie jakiś partner biznesowy (mikro firma), który współpracuje z bankami (zwykle kilkoma / kilkunastoma)
2. Banki dostarczają swoim partnerom różnego rodzaju kalkulatory finansowe - są one napisane w Excelu.
3. Partner posiada kilka / kilkanaście takich kalkulatorów (od każdego banku osobno). Każdy kalkulator ma całkiem sporo wspólnych danych do wprowadzenia, ale ma też dane specyficzne, które występują tylko w jednym z nich. Żeby porównać oferty pochodzące z różnych banków należy najpierw użyć pierwszego kalkulatora, później w drugim wpisać chyba większość rzeczy takich samych jak w pierwszym. I tak z każdym kalkulatorem.

Uwagi dotyczące potencjalnego projektu:

1. Celem projektu jest automatyzacja powyższych czynności. Chodzi o to aby partner wpisał tylko tyle danych ile musi wpisać i tylko raz a nie do każdego kalkulatora osobno. Pola typu "combo box" mogą zostać wybierane automatycznie. Dla przykładu jeżeli jest pole typu "płeć" (hipotetyczny przykład, nie pamiętam czy takie pole jest w rzeczywistości) to aplikacja, która chciałbym napisać może najpierw w tym polu wybrać opcje "mężczyzna" a później "kobieta" - w ten sposób dokona obliczeń dla obu płci i zaprezentuje je w danych wyjściowych.
2. Wynikiem działania jest zestawienie wyników pochodzących z wielu kalkulatorów (możliwość ich porównania itd.)
3. Projekt jest rozważany z myślą o niewielkiej jednoosobowej firmie, która może współpracować z innymi zaprzyjaźnionymi firmami z tej samej branży (raczej również JDG). Być może współpracownicy mieliby dostęp do tego samego systemu.
4. Rozważam realizacje projektu dla znajomej mi osoby - to takie dodatkowe zajęcie (o ile w ogóle będzie zrealizowany). Nie jest to żadne rozwiązanie korporacyjne ani nic z tych rzeczy. Między innymi z tego powodu mile widziana jest redukcja kosztów (jeżeli da się uniknąć kupowania licencji i wyższych kosztów stałych np. w postaci serwera dedykowanego z Windowsem to byłoby miło).
5. Projekt jeżeli miałby ruszyć to zacząłby się od realizacji powyższych celów ale niekoniecznie musi się na tym skończyć. Rozważać można automatyzacje innych procesów oraz implementacje dodatkowych funkcjonalności (w tym integracje z innymi systemami, np. z oprogramowaniem księgowym).

Generalnie to najlepiej by było gdyby banki udostępniały jakieś API do tego typu celów. Byłoby to najlepsze rozwiązanie. Trzeba będzie się chyba dowiedzieć czy da się to zrobić w ten sposób :) Problem tylko w tym, że wystarczy, że jeden bank nie będzie chciał tego API udostępnić i wtedy nici z eleganckiego rozwiązania problemu :)

S4t napisał(a):

No ale jak ktoś się pomyli w Excelu to też tak będzie.

To już nie mój problem :)

S4t napisał(a):

Ale jak ci zmienia pliki - np dołożą kolejne kolumny to twój wypełniacz też się wykrzaczy.

Zgadza się ale jest to dość szybkie do poprawienia.

@tk:

To nie jakiś klikacz / /rejestrator / makrogenrator klawiatury ?

Bo w gruncie rzeczy jak bank przepracuje ofertę (bo nowy vice bedzie sie musiał wykazać) to te arkusze nawet układem nie będą podobne do porpzednich

No to dla takiego przypadku najłatwiejsze i najtańsze rozwiązanie to wgranie tych plików na dysk google i stworzenie prostego skryptu https://developers.google.com/sheets/api/guides/concepts
Kiedyś sobie napisałem w googlu automatyczny skrypt który reagował na przychodzące maile z allegro, pobierał i usuwał pierwszy wiersz z tabelki w excelu i automatycznie odpowiadał na maila z kluczem produktu i linkami - całość za darmo i napisanie tego nie zajęło więcej niż 2 godziny włącznie z weryfikacją SPF maila (na wszelki wypadek żeby mi ktoś nie podrobił maila z allegro) i testami bez wcześniejszej znajomości API. Napisanie tego co potrzebujesz nie powinno zająć dużo więcej.
Możesz stworzyć aplikację i wystawić api na serwerze googla i komunikować się z nią z poziomu C#. Albo w ogóle odpuścić sobie aplikację desktopową.

W dodatku może w ogóle nie potrzebujesz pisać żadnej aplikacji - nie znam excela w 100% ale z tego co wiem to takie funkcje ma już w sobie - można połączyć komórki ze swojego dokumentu z komórkami z zewnętrznych dokumentów
https://support.microsoft.com/en-us/office/create-an-external-reference-link-to-a-cell-range-in-another-workbook-c98d1803-dd75-4668-ac6a-d7cca2a9b95f
lub stworzyć makro które będzie to robiło (niestety chyba tylko możliwe w VBA).
Można zrobić plik excela który będzie robił wszystko to o czym piszesz.

Rozwiązania chmurowe google są bardzo mocno z tyłu za microsoftem.
Hasło - API w google i szukanie czegokolwiek w tym kierunku to strata czasu.
Równie dobrze można szukać info API dla office365, ale też to nic nie da jeżeli nie wie się z czym ma się do czynienia.
Excel a dalej office365 z całą rodziną PowerPlatforms to mocno zaawansowane rozwiązania chmurowe.

Jedyne rozsądne rozwiązanie to tak jak kolega obscurity zasugerował rozwiązanie w samym excelu.
Ale też nie wiem czy coś Ci to da, jeżeli nie masz doświadczenia w programowaniu VBA dla office, i bardzo dobrze nie znasz excela.
Wbrew pozorom i wbrew ogólnej bardzo niesłusznej opinii,
cała platforma VBA i programowanie chociażby pod jedno narzędzie Excel to kawał wiedzy którą trzeba posiąść.
Sam mocno rozbudowany model obiektowy excela z setkami metod, do tego setki natywnych funkcji-metod w arkuszu,
Power Query i język M, Power Piwot i język DAX, mnóstwo innych narzędzi wbudowanych w excelu.
Dla rozwiązań chmurowych excela JavaScript.
Jeśli nigdy nie robiłeś żadnych rozwiązań pod pakiet office, to moim zdaniem powinieneś odpuścić temat.
Albo .... do czego zachęcam, parę dobrych, grubych książek i nauka czegoś nowego, tylko że czasowo się nie wyrobisz ;)