Czego w Delphi używacie do wygenerowania tego linku do QR Kod II ?
Chodzi oczywiście o ten podpis..
I jeszcze zastanawia mnie to:
"Ciąg do podpisu jest najpierw haszowany algorytmem SHA-256, a następnie generowany jest podpis zgodnie ze schematem RSASSA-PSS."
czyli ten przykładowy link
ksef-test.mf.gov.pl/client-app/certificate/Nip/1111111111/1111111111/01F20A5D352AE590/UtQp9Gpc51y-u3xApZjIjgkpZ01js-J8KflSPW8WzIE
Najpierw robie z niego hash SHA-256 i dopiero podpisuje ?
Mały przegląd szykujących się lub ostatnich zmian, i które ich prosiłem i które wsparliście:
Szkoda tylko, że tak późno dopiero system nabiera kształtów. Wciąż uważam, że data 1.02 za wczesna jak na to, co się dzieje.
Czy ktoś miał problem, że walidacja struktury logicznej faktury plikiem xsd idzie masakrycznie wolno? Dla FA1 jest ok, ale po zmianie .xsd na obecne FA2 w Java trwa już do minuty czasu
Mam pytanie export paczek cały czas jest pusty, jak pobieram po /invoices/ksef/{ksefNumber} to odsyła ok, w exporcie jako filtry podaje dateType=Invoicing, date od i do i
[▼
"status" => array:2 [▶]
"completedDate" => "2025-10-24T07:22:08.1247449+00:00"
"package" => array:7 [▼
"invoiceCount" => 0
"size" => 0
"parts" => []
"isTruncated" => false
"lastIssueDate" => null
"lastInvoicingDate" => null
"lastPermanentStorageDate" => null
]
mam pytanie do piszących w PHP, jak podchodzicie do czekania na odpowiedzi z ksef, bo asynchroniczności w PHP nie kojarzę ?
Do Delphi - umiecie ten adres do PUTa przekazać do komponentów REST? Cuduję już na wszystkie sposoby i ciągle albo mam wszystko zdekodowane, albo procenty enkoduje... Już to rozbijam na części i w cały świat wychodzi...
OldBase := Self.fRESTClient.BaseURL;
try
Url := aUploadData.Url;
p1 := Url.IndexOf('/', 10);
p2 := Url.IndexOf('?', p1);
Self.fRESTClient.BaseURL := LeftStr(Url, p1);
Params := TStringList.Create;
try
Params.Delimiter := '&';
Params.DelimitedText := Url.Substring(p2 + 1);
Url := Url.Substring(p1, p2 - p1 + 1);
for p1 := 0 to Params.Count - 1 do
begin
Url := Format('%s%s={%1:s}&', [Url, Params.Names[p1]]);
Self.fRESTClient.RESTRequest.AddParameter(Params.Names[p1], {TNetEncoding.URL.Decode}(Params.ValueFromIndex[p1]), TRESTRequestParameterKind.pkURLSEGMENT, [TRESTRequestParameterOption.poDoNotEncode, TRESTRequestParameterOption.poTransient]);
end;
System.Delete(Url, Url.Length, 1);
finally
Params.Free;
end;
Result := Self.fRESTClient.SendRequest(
aPart.Content,
TRESTContentType.ctAPPLICATION_OCTET_STREAM,
Url,
StrToRequestMethod(aUploadData.Method));
finally
Self.fRESTClient.BaseURL := OldBase;
end;
EDIT, trafiłem wreszcie:
Self.fRESTClient.RESTRequest.AddParameter(Params.Names[p1], TNetEncoding.URL.Decode(Params.ValueFromIndex[p1]), TRESTRequestParameterKind.pkURLSEGMENT, [TRESTRequestParameterOption.poTransient]);
Ależ to problematyczne potrafi być. Może się komuś przyda, zostawiam.
Mam pytanie, pobieram z KSEF faktury wg dat zapisania ich w ksef. Następnie spółki mojej firmy pobierają te faktury do siebie po dacie wystawienia faktury, tylko co jeśli do ksef wpadnie faktura z pole fa p1 czyli data wystawienia faktury sprzed 10 dni ? chyba że po innym polu powinni to pobierać ? chodzi mi oto żeby im nie poginęły faktury
Testowałem apkę mf (https://github.com/CIRFMF/ksef-docs/blob/main/auth/testowe-certyfikaty-i-podpisy-xades.md), tworzy requesta i go poprawnie wysyła. Jednak gdy tworze kolejnego requesta (bez wysyłania) i ręcznie próbuję go wysłać przez postmana dostaje zwrotkę z błędami. Wysyłane na https://ksef-test.mf.gov.pl//api/v2/auth/xades-signature?verifyCertificateChain=false
co robię nie tak?
<AuthTokenRequest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://ksef.mf.gov.pl/auth/token/2.0">
<Challenge>20251024-CR-2C6D043000-25500692A8-D3</Challenge>
<ContextIdentifier>
<Nip>5269320898</Nip>
</ContextIdentifier>
<SubjectIdentifierType>certificateSubject</SubjectIdentifierType>
<Signature Id="Signature" xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
<Reference URI="">
<Transforms>
<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>ijyAjHFJUMcK5EZu13N+QCZp77mhZBDcfq9TN7OSDdA=</DigestValue>
</Reference>
<Reference URI="#SignedProperties" Type="http://uri.etsi.org/01903#SignedProperties">
<Transforms>
<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>ppmg9MumaGPkfJVdURl4IVxqVqaeFz+yNf3BDdmD87Y=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>LcUl2OGfvUJWJ8uHL1WzzPWT+cKf/NanhbrAXvx7uFBXwQ+hqZwEheUAuM71ho0E/bDNY0LJfk/ljnkRKH/Xy3mpLbkHp5mDoy2uJunXrZgkvK9nWVemXiw03lw551MyUlY7nCnHl7yNBtVeTTKCThCXNJH5OcGpHksLrwviT8xurc8wcg522nrB654pAGi4TCaqVnQa0P5PDK2pDvbZTMTgS4YEO8uphMcFNpWmoIvZ6ClXNftpclQkRhS3MEz+PJ3MOWYJKXn9qXzIBP87b/S0QSauwtcITBKkqRvA7FhrN9i1n+qJu1fYRDF+JvjI1sLeSnK0mKyKURS7kvje9g==</SignatureValue>
<KeyInfo>
<X509Data>
<X509Certificate>MIIDfTCCAjWgAwIBAgIJAKOPVK8ez+6nMD0GCSqGSIb3DQEBCjAwoA0wCwYJYIZIAWUDBAIBoRowGAYJKoZIhvcNAQEIMAsGCWCGSAFlAwQCAaIDAgEgME4xCzAJBgNVBAYTAlBMMQwwCgYDVQQDEwNBIFIxGTAXBgNVBAUTEFRJTlBMLTUyNjkzMjA4OTgxCjAIBgNVBAQTAVIxCjAIBgNVBCoTAUEwHhcNMjUxMDI0MTE1NTI0WhcNMjcxMDI0MTI1NjI0WjBOMQswCQYDVQQGEwJQTDEMMAoGA1UEAxMDQSBSMRkwFwYDVQQFExBUSU5QTC01MjY5MzIwODk4MQowCAYDVQQEEwFSMQowCAYDVQQqEwFBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsp8XgGt59urTfBoCAfy3j+39xY3KA18yoscKp+suB4r+zCUANUwf0yOMSJOAkQq/otYqWsNxR4X5qH9zp5dtQSh/vjRN9CSpVUKn6Uo86kkCbn7qFGnmXsVp6h96+3LuOx9uclgVmtLQodvePylJkrQNDmi6I7GyV2QdgfdGRm4gJ4FcPDm4lbGXZHq4QIlClux1zMy8DnSv2FArRYRBIYF0y55wJmOgmsz5yS2Q1BgvfNHzgbTiCe/VnNTIlzS+RDeSPns+vBYhF0EfkIDdE2cSTnQvTAwdjhrrEfuIhcuM3fNxyyaB+5wTPGtgHtmQckgeC1hHSUgBejeRLQ5GfQIDAQABMD0GCSqGSIb3DQEBCjAwoA0wCwYJYIZIAWUDBAIBoRowGAYJKoZIhvcNAQEIMAsGCWCGSAFlAwQCAaIDAgEgA4IBAQBdwhtToV8s3gPnfegBsv4NBZqKm8M6rf/sBqCqzCiL5uQ/4At0tieZNaDmlr0yi5QaOWutYmFp592hEMWXRkH9ECY1tqV16Nu8uxEv+2b3xA9gV+ZRGQ84o8XJCOlVFIE4btI5kjl8EtlaQPQzl0Pn1ceRQdyyGVdEMe8FhHPoNLBHWNMahbgaQwGpNTlSwrt+7zdnSjSCGogPjS+MZiQWJu0XL2eDbtsAQlYQwJB1nCakP2JJY0T3TZrBu4AEqNcQgSuanIbGrQlIWzFPN4j1VYk4mdWE2xk4GdhC0T+q1UZQ5FZLNFNMSKmJ1H22X3pJWg8uFuVcsM/oLzQocSV3</X509Certificate>
</X509Data>
</KeyInfo>
<Object>
<xades:QualifyingProperties Target="#Signature" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns="http://www.w3.org/2000/09/xmldsig#">
<xades:SignedProperties Id="SignedProperties">
<xades:SignedSignatureProperties>
<xades:SigningTime>2025-10-24T12:55:24.0897753+00:00</xades:SigningTime>
<xades:SigningCertificate>
<xades:Cert>
<xades:CertDigest>
<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
<DigestValue>fFu6Bs7Y6A5B+yk+w9wYK4ly1wo2YjJn5oQfCyj47/Y=</DigestValue>
</xades:CertDigest>
<xades:IssuerSerial>
<X509IssuerName>G=A, SN=R, SERIALNUMBER=TINPL-5269320898, CN=A R, C=PL</X509IssuerName>
<X509SerialNumber>11785731860964830887</X509SerialNumber>
</xades:IssuerSerial>
</xades:Cert>
</xades:SigningCertificate>
</xades:SignedSignatureProperties>
</xades:SignedProperties>
</xades:QualifyingProperties>
</Object>
</Signature>
</AuthTokenRequest>
{
"exception": {
"exceptionDetailList": [
{
"exceptionCode": 9105,
"exceptionDescription": "Nieprawidłowy podpis.",
"details": [
"Nieprawidłowa wartość skrótu dla referencji wskazującej na element ''.",
"Nieprawidłowa wartość skrótu dla referencji wskazującej na element '#SignedProperties'."
]
}
],
"serviceCode": "00-c6d86a249fb0b36f63aa5f76e1cd5fd3-a05d3b5f02f9b098-00",
"timestamp": "2025-10-24T13:07:19.762251Z"
}
}
To może się przydać: jakiś czas temu zauważyłem w bibliotece .NET MF nowy serwis o nazwie IPersonTokenService, z jedyną metodą, zwracającą strukturę o niepozornej nazwie PersonToken.
Metoda istnieje od RC 5.1.1, jest wykorzystywana w testach towarzyszących bibliotece, ale nie pojawia się w żadnej dokumentacji. Wczoraj szukałem w API czegoś, co zwracałoby informację "kim jestem i gdzie jestem" z punktu widzenia KSeF. Okazuje się, że te informacje są "zaszyte" w accessToken, i że ten serwis służy do ich odczytania.
Wypełniona przez IPersonTokenService struktura PersonToken może wyglądać podobnie, jak w poniższym przykładzie: (taki efekt uzyskałem na serwerze TEST, dla użytkownika z podmiotu o Nip:52...86, pracującego w kontekście Nip:77...39):
{
"issuer": "ksef-api-te",
"audiences": [ "ksef-api-te" ],
"issuedAt": "2025-10-24T07:12:28+00:00",
"expiresAt": "2025-10-24T07:27:28+00:00",
"roles": [ "InvoiceRead", "InvoiceWrite" ],
"tokenType": "ContextToken",
"contextIdType": "Nip",
"contextIdValue": "77######39",
"authMethod": "InternalCertificate",
"authRequestNumber": "20251023-AU-37B12AE000-5252182A0A-92",
"subjectDetails":
{
"subjectIdentifier": { "type": "Nip", "value": "52######86" },
"givenNames": [],
"commonName": "ZigZak",
"countryName": "PL"
},
"permissions": [ "InvoiceRead", "InvoiceWrite" ],
"permissionsExcluded": [],
"rolesRaw": [],
"permissionsEffective": []
}
Zwróćcie uwagę, że Nip podmiotu (użytkownika) w subjectIdentifier jest różny od Nipu kontekstu, w którym był zalogowany (contextIdValue). (Nip:77...39 udzielił wcześniej Nip:52...86 uprawnień InvoiceRead, InvoiceWrite, dzięki czemu Nip:52...86 może się zalogować do jego kontekstu). Nie sprawdziłem jeszcze tego, ale zapewne w subjectIdentifier jest podawane ID wskazane w <SubjectIdentifierType> w strukturze żądania przesyłanej podczas logowania. Jak się zaloguję w DEMO za pomocą ePUAP, to pojawi się zapewne tu mój PESEL. A zawartość pól contextId* pochodzi z pola <ContextIdentifier> tej samej struktury.
Używając tej metody, można łatwo w każdym momencie przetwarzania sprawdzić aktualny kontekst i podmiot, bez żadnych odwołań do innych zasobów zewnętrznych. W wielu przypadkach to się może przydać. Dla tych, którzy piszą w innych środowiskach: tutaj jest implementacja tego serwisu.
Być może coś przeoczyłem, bo wygląda to dość nieintuicyjnie. Załóżmy, że jestem integratorem i obsługuję 1000 klientów, z których każdy posiada własne urządzenie, które musi mieć możliwość wystawienia faktury w trybie offline24 (bez internetu).
Czy dobrze rozumiem, że aby to zrealizować, musiałbym na każde urządzenie przesłać swój certyfikat KSeF wraz z kluczem prywatnym, aby to urządzenie mogło nim podpisać fakturę (zakładając, że klient nada mi uprawnienia do wystawiania faktur w jego imieniu)?
W takim scenariuszu wyciek z choćby jednego urządzenia umożliwiłby osobie niepowołanej wystawianie i przesyłanie faktur w imieniu dowolnego z moich 1000 klientów — dobrze to rozumiem?
Nie widzę też w KSeF możliwości przypisania konkretnego certyfikatu do konkretnego klienta, a dodatkowo liczba certyfikatów jest ograniczona do 100. Czy poprawnie interpretuję ten proces (flow), czy coś pomijam? Czy takie flow powinno wyglądać inaczej?
Czy istnieje sposób na uzyskanie certyfikatów ksef za pośrednictwem aplikacji (KSeF UI lub czegoś podobnego), czy też musimy o nie wnioskować za pomocą interfejsu API po uprzednim uwierzytelnieniu za pomocą E-Seal?
Coś źle robię, czy tak ma być, że api/v2/security/public-key-certificates zwraca te same certyfikaty dla środowiska testowego i demo? Dla produkcyjnego też będą te same?
W jaki sposób generować certyfikaty KSEF dla firmy z kilkoma oddziałami.
Czy ktoś używa walidacji AuthTokenRequest wg ich schemy XSD https://ksef-test.mf.gov.pl/docs/v2/schemas/authv2.xsd ? Nie wiem jak w innych językach, ale w PHP... rzuca errorami, że znaki w tym XSD są źle escapowane xD
Wrzuciłem zawartość tego pliku do ChatGPT i wypluł mi poprawiony dokument, w którym walidacja już przechodzi...
Kto może krok po kroku wyjaśnić proces autoryzacji za pomocą certyfikatu?
W przypadku autoryzacji tokenem, poprzez /redeem otrzymuję accessToken i refreshToken, używam refresh do uzyskania nowej sesji, jeśli refreshToken wygasł, powtarzam autoryzację tokenem.
A jak działają certyfikaty? Jak zalogować się za pomocą certyfikatu? Jak następnie zalogować się automatycznie bez użytkownika?
Mógłby dla mnie ktoś sprawdzić jedną rzecz? Bo sobie jeszcze nie natworzyłem faktur więcej niż kilka do wysyłania jak do tej pory.
https://ksef-test.mf.gov.pl/api/v2/sessions/{referenceNumber}/upo/{upoReferenceNumber} czy tam jest jeden plik z XML nawet dla 10k faktur?
Z kolei poprzez https://ksef-test.mf.gov.pl/api/v2/sessions/{referenceNumber} będzie dla tej samej sesji x [ile?] plików (stron)?
Mam pytanie - co robię źle próbując nadać "samemu sobie" uprawnienia na TEST przez EP "testdata/permissions" przesyłając:
{ "contextIdentifier": { "type": "Nip", "value": "1.....1" },
"authorizedIdentifier": { "type": "Nip", "value": "1.....1" },
"permissions": [
{ "type": "CredentialsManage", "description": "test pemrs" },
{ "type": "CredentialsRead", "description": "test pemrs" },
{ "type": "Introspection", "description": "test pemrs" },
{ "type": "SubunitManage", "description": "test pemrs" },
{ "type": "EnforcementOperations", "description": "test pemrs" }
]}
a w odpowiedzi dostaję (w json ale streszczę): 500 - nieoczekiwany błąd?
EDIT 1:
nip podaję dwa razy ten sam i jest "prawdziwy".
EDIT 2:
puściłem też "testdata/permissions/revoke" (by wyczyścić ew. śmieci) - poszło ok (status 200), ale nadanie jak wcześniej bez zmian - 500.
EDIT 3:
"solved" - nie było tematu - powyższe wynika z mojego niezrozumienia ścieżki postępowania (nie użyłem wcześniej EP testdata/person)
Czy w środowisku demo działa autoryzacja pieczęcią firmową? Mam firmę zgłoszoną do KSeF w czasach wersji 1.0. Teraz próbuję się autoryzować pieczęcią tej firmy. Dostaję token autoryzacyjny, ale pytanie o jego status zwraca mi błąd HTTP 401 - czyli jakiś problem z autoryzacją?
dlaczego serwer testowy ksef nie odpowiada ??????????????
Challenge: 20251027-CR-2D29D75000-05D901370A-59
----- Podpisany XML (skrócony) -----
initializationVector:
o4ZQvE5sAyVVWRa6P12Klw==
[ próba 1 z 3 ] Otwieranie sesji...
[?] Sesja otwarta pomyślnie.
referenceNumber: 20251027-SO-2D2D6D2000-05DFA67CBA-D7
Sesion token(referenceNumber): 20251027-SO-2D2D6D2000-05DFA67CBA-D7
?? Odpowiedź testowa: 404 NotFound
Treść odpowiedzi:
Status HTTP: 202 Accepted
Treść odpowiedzi:
{"referenceNumber":"20251027-EE-2D2D91E000-39568AD0DF-D9"}
[? Próba 1/20] Sprawdzanie statusu faktury: 20251027-EE-2D2D91E000-39568AD0DF-D9
Treść odpowiedzi WaitForAcceptanceAsync:
[!] Błąd HTTP: 404 NotFound
?? Faktura nie została jeszcze zarejestrowana - prawdopodobnie nadal przetwarzana.
Treść odpowiedzi:
[? Próba 2/20] Sprawdzanie statusu faktury: 20251027-EE-2D2D91E000-39568AD0DF-D9
Treść odpowiedzi WaitForAcceptanceAsync:
[!] Błąd HTTP: 404 NotFound
?? Faktura nie została jeszcze zarejestrowana - prawdopodobnie nadal przetwarzana.
Treść odpowiedzi:
I mamy piątą aktualizację w niecały miesiąc od publikacji :)
Zwiększyli np. max pageSize przy pytaniach o statusy sesji.
Ale okazuje się też, że... linki do UPO mają ważność! :o to dość znacząca zmiana wymagająca reorganizacji.
Jest jakiś limit wywołań /api/v2/auth/token/refresh, czy można to wywoływać np. przed każdą inną operacją wymagającą accessToken?
Są jakieś zalecenia kiedy / jak często wywoływać ten endpoint?
Cześć, pytanie o pobieranie/eksport faktur - tzn. pobieram paczkę zainicjowaną przez /api/v2/invoices/exports. Zip zawiera plik metadanych w formacie json oraz pliki xml faktur. Jak wiążecie informacje o metadanych z plikiem XML? Da radę to zrobić bez parsowania XML? Liczyć skrót XMLi? Bo taką daną znalazłem w metadanych. Szkoda, że nie ma nazwy pliku xml.
Pytanie ogólne, na które nie znalazłem odpowiedzi w poprzednich wątkach:
Zastosowałem następującą procedurę wysyłania pojedynczej faktury za pomocą sesji interaktywnej:
Zapytanie o status uwierzytelnienia z wykorzystaniem tokena uzyskanego podczas ostatniego uwierzytelnienia (api/v2/auth/{referenceNumber})
Jeżeli otrzymuję odpowiedź 401, wykonuję uwierzytelnienie za pomocą pomocą xades (api/v2/auth/xades-signature); czekam na "Uwierzytelnianie zakończone sukcesem" - code 200 (api/v2/auth/{referenceNumber})
Sprawdzam, czy ostatnio pozyskany access token jest ważny (sprawdzam datę ważności); jeżeli nie - robie refresh token (api/v2/auth/token/redeem)
Otwieram sesję interaktywną i wysyłam 1 fakturę: api/v2/sessions/online/{referenceNumber}/invoices
zamykam sesję (api/v2/sessions/online/{referenceNumber}/close) i czekam na status "Sesja interaktywna przetworzona pomyślnie" - code 200
pobieram numer ksef: api/v2/sessions/{referenceNumber}/invoices
Czy też tak robicie?
Czy coś poprawić?
Mam pytanie czy jest jakaś końcówka do sprawdzenia daty ważności certyfikatu, bo po 2 latach staje się nie ważny żeby dać jakieś przypomnienie ?
Jak to jest z certyfikatem klucza publicznego? On sam w sobie nie jest kluczem publicznym nie? czyli jak chcę wykorzystać klucz publiczny do wysyłki wsadowej,to muszę ten certyfikat klucza publicznego zamienić w plik pfx?
Siewek napisał(a):
Jak to jest z certyfikatem klucza publicznego? On sam w sobie nie jest kluczem publicznym nie? czyli jak chcę wykorzystać klucz publiczny do wysyłki wsadowej,to muszę ten certyfikat klucza publicznego zamienić w plik pfx?
pobierasz certyfikat w formacie DER i niego trzeba wyeksportować klucz publiczny
openssl.exe x509 -inform DER -in ksefPubCert.der -out ksefPubCert.pem
openssl.exe x509 -in ksefPubCert.pem -pubkey -out ksefPublicKey.pem
Cześć, wysyłając faktury w ramach jednej sesji interaktywnej, pierwsze kilka przechodzi w porządku (wysyłam, a gdy wysyłka bez błędów po chwili sprawdzam status).
Potem jednak pobierając status dostaję błąd 435 Błąd odszyfrowania pliku. Szczegóły: Plik niepoprawnie zaszyfrowany.
Jednak gdy zamknę sesję, otworzę nową interaktywną, ta sama faktura, która miała być błędnie zaszyfrowana, wysyłana jest w porządku otrzymując status 200.
Po wysyłce kilku kolejnych, błąd się powtarza i żeby faktura, która rzekomo jest błędnie zaszyfrowana dostała poprawny status, muszę znowu zamknąć sesję i wysłać ją ponownie i tak w koło.
Czy ja tu coś źle robie, czy to może jest jakiś błąd po stronie ksefu? Spotkał się ktoś z czymś takim?
W paczkach z eksportem faktur pojawił się na test plik z metadanymi, a na demo nie ma. Aktualizacja była tylko na teście?
Dziś MF podtrzymało, że terminu nie zmienią (w artykule wpis z FB - daję tak, bo FB sam nie mam):
https://www.pit.pl/aktualnosci/ksef-czy-bedzie-przesuniecie-terminu-1011826