Intelliware

O que observamos é que para o CST00 consegue transmitir normal, para o CST60 mesmo preenchido o campo retorna rejeição comunicando que não está preenchido.

Estamos recebendo também o mesmo erro com o campo <orig> preenchido com 0 para o CRT=3.

Bom dia @zenilda. Você conseguiu mais alguma informação sobre o assunto em questão?

Beleza, vamos estar implementando aqui e qualquer coisa retornamos para vocês.

No MOC(Manual de Orientação do Contribuinte Anexo II – Manual de Especificações Técnicas do DAMDFE Versão 3.00a – abril (2019)) consta apenas: "Na impressão do DAMDFE deve ser utilizado papel comum nas orientações retrato ou paisagem. O papel utilizado deve garantir a legibilidade das informações impressas por, no mínimo, doze meses." No mesmo documento chega a ter um exemplo mais é apenas do modo retrato. Acreditamos que o modo paisagem seja apenas um redimensionamento do tamanho dos campos do modo retrato.

Bom dia, Estávamos validando no projeto e não conseguimos imprimir em modo paisagem. Gostaríamos de saber se este tipo de layout está em desenvolvimento por algum membro e se não estiver se podemos desenvolver ou tem alguma restrição para não contemplar no projeto. Desde já agradeço.

No nosso caso aqui, conseguimos transmitir posteriormente a nota. Era algum problema realmente na SEFAZ. Agradeço a resposta de todos.

@Juliomar Marchetti, no caso, já atualizamos no cliente os schemas e não encontramos nenhuma má formação no xml gerado.

Bom dia pessoal, Estamos com a seguinte CTE desde sexta-feira(13/01/2023) que só nos retorna erro não catalogado, segue: <?xml version="1.0" encoding="UTF-8"?> <eventoCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="3.00"> <infEvento Id="AQUI TAMBÉM TEM A CHAVE DO CTE. REMOVI"> <cOrgao>31</cOrgao> <tpAmb>1</tpAmb> <CNPJ>XXXXXXXXXXXXXX</CNPJ> <chCTe>XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX<chCTe> <dhEvento>2023-01-16T09:18:05-03:00</dhEvento> <tpEvento>110110</tpEvento> <nSeqEvento>1</nSeqEvento> <detEvento versaoEvento="3.00"> <evCCeCTe> <descEvento>Carta de Correcao</descEvento> <infCorrecao> <grupoAlterado>compl</grupoAlterado> <campoAlterado>xObs</campoAlterado> <valorAlterado>Este documento est vinculado ao documento fiscal de serie 001 e numero 8156, na data 03/01/2023, em virtude de questoes logisticas inesperadas, acrescimo de custos logisticos. CTE complementar ao CTE 8156 referente a tres diarias autorizada pelo Sr. Helder </valorAlterado> <nroItemAlterado>01</nroItemAlterado> </infCorrecao> <xCondUso>A Carta de Correcao e disciplinada pelo Art. 58-B do CONVENIO/SINIEF 06/89: Fica permitida a utilizacao de carta de correcao, para regularizacao de erro ocorrido na emissao de documentos fiscais relativos a prestacao de servico de transporte, desde que o erro nao esteja relacionado com: I - as variaveis que determinam o valor do imposto tais como: base de calculo, aliquota, diferenca de preco, quantidade, valor da prestacao;II - a correcao de dados cadastrais que implique mudanca do emitente, tomador, remetente ou do destinatario; III - a data de emissao ou de saida. </xCondUso> </evCCeCTe> </detEvento> </infEvento> <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/2000/09/xmldsig#rsa-sha1"/> <Reference URI="#ID1101103123010566315100014357001000008197128388318201"> <Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/></Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue>Mnz8NZBo9sak5TOMvvVGawqGe9Q=</DigestValue> </Reference></SignedInfo> <SignatureValue>XCFgscECyy+ybW0K9TlubRAzPC3qjz2YOCmQ0IDP0WdcLNa6Q9KhNTkBGbB5PpoToAap6hYSJGjpowKlFqvzB2ZnOeZHzt1Ara ik0xBYzPe0phMsmSIf3xYEUIpGZjUdypPalCAqyapGO5kiecTzM1OMzkq0IJ7CDROhCol8UFcreYpgjiSJe4CWshrpRVDHjG8o40UKUf1WY+Ey5ejSjqqxP6MBn8GmCeJiI23z+lyE nmGVWebQINmFRdh4bJIJgbDM/ALsBzcpolswSgulmkiaIh5X/nZqL8eO0uAO7tOuW+OWCRdNlViEokB7/POF276nH5FiDjIP6QcMzNeU1Q==</SignatureValue><KeyInfo> <X509Data><X509Certificate>MIIHCTCCBPGgAwIBAgIIcnQiCRRS1oIwDQYJKoZIhvcNAQELBQAwWTELMAkGA1UEBhMCQlIxEzARBgNVBAoTCklDUC1CcmFzaWwxFTATBgNVBAsTD EFDIFNPTFVUSSB2NTEeMBwGA1UEAxMVQUMgQ0VSVElGSUNBIE1JTkFTIHY1MB4XDTIyMDkxNTEyMDIwMFoXDTIzMDkxNTEyMDIwMFowgcIxCzAJBgNVBAYTAkJSMRMwEQYDVQQKEwpJQ1A tQnJhc2lsMR4wHAYDVQQLExVBQyBDRVJUSUZJQ0EgTUlOQVMgdjUxFzAVBgNVBAsTDjQ1MzEwNDY4MDAwMTEwMRkwFwYDVQQLExBWaWRlb2NvbmZlcmVuY2lhMRowGAYDVQQLExFDZXJ0 aWZpY2FkbyBQRiBBMTEuMCwGA1UEAxMlRURJTUlMU09OIE1JR1VFTCBEQSBTSUxWQTowNjMwMTk2ODY5NzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK6aiNZWabf4X1Z 4YVCuaj1af9/HrxIVNCPlu0iUBthmFPS3qWorHzO3/rFUOY2bS7pKsUSU5GGlfifIt32gDOtZE3r70phDD6H/d3wK3fZwGnWzlZkUYJjWAPtBzB5hH3CDmWmAWE0DnJrLvblgKfYQm VHWYWmkAwou1VXSDOJ6ht6N5svRnxK5ZwEZ6Z7nfTm+Kj8xPSXD28WlsBhXkc6J4zJGpMUqvOYDRrKyL6jFc4g7RwQZYmXY9sLVx5OnfXuETquboSRX0+AffKGXCrAWVu2+t6VynDo rH4k0G7kODxNh2djxGfi2WJhblixte1Y2b6xcdsBtqyX0ZLv1y0UCAwEAAaOCAmkwggJlMB8GA1UdIwQYMBaAFD/TXKkZTdeIFi2YDK8K3uFPJBawMFkGCCsGAQUFBwEBBE0wSzBJB ggrBgEFBQcwAoY9aHR0cDovL2NjZC5hY3NvbHV0aS5jb20uYnIvbGNyL2FjLWNlcnRpZmljYW1pbmFzLXNtaW1lLXY1LnA3YjCBmwYDVR0RBIGTMIGQgRt0b21hdGVzaXRpb21pZ3 VlbEBnbWFpbC5jb22gOAYFYEwBAwGgLxMtMzAwODE5ODkwNjMwMTk2ODY5NzAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwoBcGBWBMAQMGoA4TDDAwMDAwMDAwMDAwMKAeBgVgTAEDBa AVExMwMDAwMDAwMDAwMDAwMDAwMDAwMGIGA1UdIARbMFkwVwYGYEwBAgFgME0wSwYIKwYBBQUHAgEWP2h0dHA6Ly9jY2QuYWNzb2x1dGkuY29tLmJyL2RvY3MvZHBjLWFjLWNlcnRpZ mljYW1pbmFzLXNtaW1lLnBkZjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwgZYGA1UdHwSBjjCBizBDoEGgP4Y9aHR0cDovL2NjZC5hY3NvbHV0aS5jb20uYnIvbGNyL2Fj LWNlcnRpZmljYW1pbmFzLXNtaW1lLXY1LmNybDBEoEKgQIY+aHR0cDovL2NjZDIuYWNzb2x1dGkuY29tLmJyL2xjci9hYy1jZXJ0aWZpY2FtaW5hcy1zbWltZS12NS5jcmwwHQYDVR 0OBBYEFJkjBGsp7QC4kWpSA8sizLyfhTdDMA4GA1UdDwEB/wQEAwIF4DANBgkqhkiG9w0BAQsFAAOCAgEAd7Sby50Tu2ZxR3CD3R8fn5lsEdrJDArN9w9P7N9wv7sbMEo8jSBp49qM KX4r58gPlTCI0Z9Vcz/59fSP3URl08u4ulNMLgOAL15pgnvWln/MLf1pR6H3OtHz3gUGhDyU+lxbus/7kXlIZ1SpobR0CEKXfIF0+S3vLGcxN089SI0lQDMYinlhowoSOLEqjA95iq kLUIZP3bp7HWKQlOIFcxP+0CXVJaUjHd0dcYORrhDFjgDwRtjwbRadq3YNpyVzEv3+wI5qQ0dDZFheq6vdm98k36TKnVEN5PPFMhh0lKw/IaMpBT0FtKF3PRcJCNJ7PUtTJGbtGX+ PPq2ZluXQwbOB0B5fLj63PPUo9dXkKkER0Y1vqZX8pytado8iV5ywBVQw3xYaZWEpyoYJRyzxdQXmXOOosJTxd1GfhelKHEzVNGBED98N1NRI5ri3ONStMvq4qR0gYEyxSLGMFQHy C9cDOzUqkaHToi2J1rVnz3fZ9bXRAKfLlosEfntOwkAci+CCL4CYTBB7mM/QzsnqBCi2+GODShlbkNNtX46+LaxMjvz2TvUQnh6VjScHdcKk6EiXg3ZYXBWqdo0jkIMudfUpzUZQ4e EpUUhQOg1ncrxNiYwiomxJSPjb61IPLzTuiKixUHLTySuuymvy/3nggM+iQlSJVLsBtalGiO+TpT0=</X509Certificate></X509Data></KeyInfo></Signature> </eventoCTe> E o retorno da SEFAZ: <?xml version="1.0" encoding="UTF-8"?> <retEventoCTe xmlns="http://www.portalfiscal.inf.br/cte" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" versao="3.0"> <infEvento> <verAplic>2.1.71</verAplic> <cStat>999</cStat> <xMotivo>Erro nao catalogado</xMotivo> </infEvento> </retEventoCTe> Alguém já teve esse problema ou pode nos orientar o que pode estar errado? Desde já agradecemos.

Usando 'TCP:' + IP_BALANCA + ':' + PORTA_TCP; Eu consigo ativá-la, mas ao ler o peso cai no timeout. Você conseguiu @rfazevedo?

Para solicitar o QRCode para ser tratado na aplicação, o manual do CARDSE pede para informar: TEFCliSiTef.Restricoes = '{DevolveStringQRCode=1}'; Antes de chamar a função 122.

Pessoal boa tarde, Acabei de receber uma mensagem da SEFAZ que o cancelamento de NFC-e foi normalizado. Tentei efetuar um cancelamento aqui em ambiente de Homologação e foi normalmente.

Obrigado por reportar @magnosystem. Estamos aguardando uma resposta da SEFAZ até o momento. O usuário @EddieBR também reportou o mesmo problema.

Boa tarde, Recebemos hoje uma mensagem da SEFAZ que a nossa requisição foi enviada á Superintendência de Tecnologia e Informação - STI. Que é para continuarmos aguardando.

Boa tarde Daniel, entramos em contato com a SEFAZ, teremos uma resposta até o dia 25/03/2019. Ficamos no aguardo.

Bom dia EMBarbosa, Eu validei a assinatura da venda que estou tentando cancelar pela chave que foi processada pelo próprio demo da ACBr e obtive: Não sei se temos um modo de validar a assinatura do arquivo do evento. Será que as configurações de criptografia ou até mesmo alguma propriedade do certificado do cliente poderia estar interferindo no cancelamento?

Boa tarde EMBarbosa, Efetuei a validação da nota que estou tentando cancelar. O resultado foi esse: Esse erro reportado de Assinatura INVÁLIDA é normal para este tipo de validador?

Pessoal boa tarde, Desde ontem, estamos recebendo relatos de dois clientes nossos de Minas Gerais que ao tentar efetuar o cancelamento de da NFC-e em Produção, está retornando 'Rejeição: Erro não catalogado', código de status 999. Analisando o problema em Homologação hoje, tenho no pedido do evento de cancelamento: E na resposta: Por favor, alguém está passando pelo mesmo problema ou poderia nos orientar sobre algum possível problema nos dados do XML? No source, o cancelamento por chave é bem simples, somente preenchemos os seguintes dados: Desde já agradeço.

Boa tarde pessoal, Realmente, vamos mandar como cancelados. Não encontramos nenhuma documentação específica sobre o assunto até o momento. Sobre a contingência, encontramos a seguinte informação: Agradeço a todos.

Boa tarde pessoal, Criamos um processo de contingência para o nosso sistema de acordo com o documento "NFC-e Manual de Padrões Padrões Técnicos Contingência Off-line 2.0". No caso, quando entramos em contingência ao emitir a NFC-e 20, por exemplo, o sistema cria a 21 e ao voltar a conexão tenta cancelar ou inutilizar o número 20, conforme o fluxograma descrito no documento. No entanto, surgiram duas dúvidas, que vou descrever abaixo: 1) No SPED, no caso específico da contingência, suponha que após restabelecer a conexão foi necessário CANCELAR a NFC-e 20 e posteriormente eu TRANSMITI a 21 com sucesso. Como entraria esta situação no SPED? O cancelamento da NFC-e teria que ser declarada mesmo eu transmitindo com sucesso a 21 que era a sua contingência? 2) Na contingência, pelo documento acima, temos descrito "o prazo de envio para autorização da NFC-e até o final do primeiro dia útil subsequente contado a partir de sua emissão em contingência". Neste caso, caso extrapole o prazo, suponha que o cliente fique dois dias sem rede, qual que seria o procedimento correto? Só para registrar estou no estado de Minas Gerais. Desde já agradeço os comentários. @Gr@c@ @Italo Jurisato Junior

Boa tarde, Notamos um pequeno errinho de ortografia no extrato gerado via ESC/POS, precisamente na linha 400 da "TACBrSATExtratoESCPOS": if (TotalDescAcresItem <> 0) then begin Sinal := IfThen(TotalDescAcresItem < 0,'-','+'); FPosPrinter.Buffer.Add(PadSpace(ACBrStr('Total de descontos/acrésimos sobre item|')+ FormatFloatBr(TotalDescAcresItem, Sinal+',0.00'), FPosPrinter.ColunasFonteCondensada, '|')); end; Obrigado.

Bom dia, os testes a que me referi acima foram feitos com os fontes atualizados da AcBr, já envolvendo as propriedades adicionadas.

Boa tarde Ala. Estamos cientes que será opcional, mas estamos atualizando nosso sistema e adequando às modificações em forma de configuração, caso algum cliente prefira utilizar o novo leiaute, uma vez que proporciona economia de papel.

Boa tarde, Fizemos alguns testes utilizando as propriedades mencionadas em alguns modelos de impressoras. Na impressora Sweda SI300S, que trabalha com apenas 42 colunas, utilizando o protocolo EscPos, o texto lateral ao QrCode ficou cortado, conforme a figura abaixo: Notamos também que a impressora Bematech não suporta este leiaute, conforme mencionado acima, mesmo forçando ela a trabalhar no protocolo EscPos no aplicativo da bematech. Haverá alguma adequação do leiaute do Fortes Report, como alternativa às impressoras que não suportam o qrCode lateral? Grato.

Boa tarde Graça, era um problema no nosso certificado. Agradeço a resposta e as configurações.