Intelliware

Bom dia Daniel e Elias. Estamos terminando o lançamento de uma versão e já vou partir para os testes com a correção. Qualquer dúvida posto aqui. Desde já agradeço.

Boa tarde pessoal, Estamos implementando correspondente bancário no nosso PDV. O componente ACBrTEF efetua todo o fluxo normalmente. Utilizamos o módulo SitCorban SE da instituição bancária Tribanco e o SitDemo 6.0.0.3. No momento, temos algumas dúvidas: 1) No caso do fluxo do TEF, quando entramos em pagamento de conta, digitamos os referidos valores que são pedidos para o primeiro boleto(valor de R$ 120,00). Após este procedimento aparece a mensagem conforme o segundo anexo abaixo. Se digitamos mais um boleto no valor de R$250,00, finalizamos o processo com o valor total de R$370,00. Na transação do TEF, observamos que no arquivo de resposta contêm apenas dados do último boleto, embora no arquivo do TEF apareça nos campos 121 e 607 indicação que temos dois boletos. Isso é o correto mesmo? Conforme o primeiro arquivo em anexo abaixo. Este questionamento se refere ao fato que estávamos pensando em obter todos os dados dos boletos apartir da resposta pendente do TEF, mas pelo que tenho de retorno, acredito que vamos ter que manipular os dados de todos os boletos inseridos apartir do evento 'TEFCliSiTefObtemCampo' de acordo com os valores da variável 'TipoCampo'. 2) Em relação ao troco, no caso do correspondente bancário, existe algum campo que retorne esta informação ou este é um tratamento que nós da automação que fazemos? Tentamos comunicação com a Software Express, mas até o momento não obtivemos nenhum retorno. Gostaríamos de saber se alguém já realizou esta implementação e poderia por gentileza nos esclarecer estes pontos. Desde já agradeço. ACBr_CliSiTef_001.tef

Entendi. Vou entrar em contato com eles para confirmar esta informação. Agradeço.

Exatamente Daniel, acabei encontrando aqui. Pelo que pude observar, acredito que na procedure ACBrTEFD.CNC, o NSU pedido é o do SiTEF(6 posições) que corresponde ao campo 133. Seria isso mesmo? Uma vez que a diferença entre o NSU do SiTEF e o NSU do Host autorizador é exatamente a diferença de zeros em questão.

Bom dia Daniel, Na verdade, não seria realmente um problema, somente uma divergência entre a quantidade de zeros a esquerda no número do documento. No caso, no banco de dados fica gravado 000010020 e no documento impresso 010020. Com isso, no momento de cancelar o operador precisa retirar os zeros sobrando a esquerda para poder efetuar o cancelamento do cupom. No caso acima: 000010020 - 000 = 010020 Vou ver se consigo mais informações utilizando o comando de debug acima. Agradeço.

Boa tarde pessoal, Estamos com a seguinte situação utilizando o SitDemo 6.0.0.3, segue: Quando efetuamos uma transação, obtemos o NSU da mesma utilizando o comando: ACBrTEFD.RespostasPendentes[pred(ACBrTEFD.RespostasPendentes.Count)].NSU Esse valor é gravado em banco. No nosso caso, fica, por exemplo: 000010020 Quando é executado o comando: ACBrTEFD.CNC(cdsGetMovCxTEFREDE.AsString, cdsGetMovCxTEFNSU.AsString, cdsGetMovCxTEFDATAHORAHOST.asDateTime, cdsGetMovCxTEFVALORFINAL.AsCurrency); Não é aceito o número do documento acima, retornado em cdsGetMovCxTEFNSU.AsString. Olhando no comprovante do TEF, temos: DOC=010020 Então, neste caso, o operador precisa apagar os três primeiros zeros para conseguir o cancelamento do cupom e da transação, gerando um certo transtorno na fila. Analisando o documento Especificação Técnica – Interface com os meios de pagamento do SiTef Bibliotecas CliSiTefI e CliSiTef Versão 172, temos na página 24 que: 133 - Contém o NSU do SiTef (6 posições) 134 - Contém o NSU do Host autorizador (20 posições no máximo) Analisando a unit ACBrTEFDCliSiTef.pas linha 376, temos: 134 : fpNSU := LinStr; Acredito que neste caso, do comando CNC do CliSiTEF eu não poderia assumir o tamanho do campo como sendo 6 e preencher com zeros a esquerda ou poderia? Gostaria de saber, se existe uma padronização para o tamanho deste campo ou se estamos efetuando algum procedimento incorreto. Desde já agradeço a opinião de vocês.

Exato, é o projeto feito em Lazarus ACBrBlocoXSign, que utilizamos como base. Agradeço.

Boa tarde Juliomar, Já criamos a interface para validar as pendências e transmissão, gravação em banco de dados, tratamento de exceção e etc... utilizando o source, que se não me engano, foi sua contribuição. Segue: 1) ecf.ACBrBlocoX.WebServices.ValidarBlocoX 2) with ACBrBlocoX.WebServices.EnviarBlocoX do begin XML := XMLaTransmitir; Executar; ReciboFiscoReducaoZ := RetWS; end; 3) with ACBrBlocoX.WebServices.EnviarBlocoX do begin XML := XMLaTransmitir; Executar; ReciboFiscoEstoque := RetWS; end; 4) with ACBrBlocoX.WebServices do begin ConsultarBlocoX.Recibo := Recibo; ConsultarBlocoX.Executar; Result := ConsultarBlocoX.RetWS; end; Teoricamente temos tudo pronto no projeto, mas não efetuamos nenhum teste ainda em ambiente de desenvolvimento pois não sabemos se pode ser efetuado a transmissão utilizando o webservice do componente.

Show. Agradeço o esclarecimento Juliomar.

Entendi Juliomar. No caso a nossa versão está prevista para daqui 12 dias e vamos ter que, pelo menos, por enquanto, manter na 02.03. O bloco X que ficou pendente a parte de transmissão, que embora a gente gere os arquivos, ainda não efetuamos nenhum teste após a implementação. Agradeço a resposta.

Boa tarde pessoal, Estamos em Minas Gerais, mas já estamos deixando o nosso sistema compatível com a ER 02.03. Implementamos o envio do BLOCO X normalmente, segundo as instruções no fórum. A dúvida que ficou, foi a seguinte: Podemos transmitir os dados do estoque e redução Z para o webservice setado no componente para fazer teste em ambiente de desenvolvimento? Esse endereço já é para homologação mesmo? Não ficou muito claro esta parte durante a leitura das informações postadas pelos outros colaboradores. Desde já agradeço.

@Juliomar Marchetti no componente ACBrBlocoX, podemos transmitir os dados do estoque e redução Z para o webservice setado normalmente para fazer teste em ambiente de desenvolvimento? Esse endereço já é para homologação mesmo? Estou em Minas Gerais e estamos homologando para a ER 02.03 e não ficou muito claro esta parte. Agradeço.

No caso de não possuir CEST, ficaria somente: (# + NCM + # + Descrição)

Só retornando a resposta, funcionou normalmente. Agradeço a todos.

Opa, valeu pelo retorno rick. Vou tentar aqui. Agradeço.

Boa tarde pessoal, No retorno da função ConsultarStatusOperacional a ACBrSAT efetua as leituras dos parâmetros: NSERIE LAN_MAC STATUS_LAN NIVEL_BATERIA MT_TOTAL MT_USADA DH_ATUAL VER_SB VER_LAYOUT ULTIMO_CFe LISTA_INICIAL LISTA_FINAL DH_CFe DH_ULTIMA CERT_EMISSAO CERT_VENCIMENTO ESTADO_OPERACAO Pela Especificação de Requisitos, existe ainda estas outras possibilidades: TIPO_LAN LAN_IP LAN_MASK LAN_GW LAN_DNS_1 LAN_DNS_2 Eu não encontrei as propriedades acima na unit ACBrSATClass.pas, elas realmente não foram implementadas? Existe um modo de obtê-las? É que o pessoal de implantação está tendo um certo trabalho para obter o referido IP que o SAT utiliza, sendo que acreditamos que seria uma informação interessante, inclusive para validar se o mesmo não está sendo bloqueado no firewall. Desde já agradeço.

Mantivemos normalmente o GTIN. No exemplo acima: 001 00000100040001 #2804300#35061090#ADESIVO BISNAGA 17GRS "COLA" 001 = Número do Item 00000100040001 = GTIN #2804300#35061090#ADESIVO BISNAGA 17GRS "COLA" = (# + CEST + # + NCM + # + Descrição) = Descrição do Item = Descrição do método 'ACBrECF.VendeItem'

Efetuamos a alteração hoje. No nosso, no campo descrição do produto, ao enviar para o ECF, adicionamos o seguinte: #CODIGO_CEST#NCM#DESCRIÇÃO DA MERCADORIA Ficaria assim no cupom: 001 00000100040001 #2804300#35061090#ADESIVO BISNAGA 17GRS "COLA" Na Bematech vai haver uma quebra na descrição, mas foi o que nos foi passado pelo homologador.

Entendi. Agradeço a informação pessoal.

Pessoal, bom dia. Alguém têm alguma informação se a partir de 01/06/2016 vai realmente vigorar para impressão em cupom fiscal o código CEST para todos os convênios utilizando o PAF-ECF? § 5º Os códigos CEST e NCM/SH, previstos no Convênio ICMS 92/15, de 20 de agosto de 2015, devem ser impressos no Cupom Fiscal no campo descrição da mercadoria, a partir do primeiro caractere, da seguinte forma: #código CEST#NCM/SH#descrição da mercadoria § 6º Ficam obrigados à regra prevista nesta cláusula os contribuintes usuários de ECF desenvolvidos nos termos deste convênio e do Convênio ICMS 85/01.”.

Alguém conseguiu efetuar a consulta dos lotes via webservice com sucesso?

Bom dia pessoal, só para dar um retorno neste tópico. Acabamos utilizando o rateio que o nosso sistema mesmo faz para efetuar o abatimento na base de cálculo do PIS/COFINS. Em uma tabela separada armazenamos os valores de rateio do SAT tanto para desconto quanto para acréscimo na subtotalização, para caso seja necessário efetuar uma comparação no futuro. Agradeço a opinião de todos.

Entendo. Mas no caso pode ficar diferente os valores de rateio que o SAT utilizou e o valor de rateio que o meu AC utilizou em cada item, não? Isso não geraria algum problema posteriormente?

Exato Ricardo, mas no caso, o desconto do rateio que veio do desconto no final do cupom é realizado pelo SAT e no momento que montamos o XML ainda não temos este valor, certo?

Bom dia pessoal, Ontem, efetuamos um teste dando um desconto no total do cupom. Esse valor, o SAT rateou entre os itens normalmente. No quarto item, efetuamos também um desconto no item. Analisando posteriormente o XML que foi retornado pelo SAT, observamos que: 1) A base de cálculo para PIS/COFINS somos nós que informamos, portanto, já é passada para o XML com o devido desconto do item 2) No caso do desconto de rateio ele não abateu em cima do valor da base de cálculo, uma vez que o rateio do cupom é realizado pelo próprio SAT A pergunta que ficou pendente foi se no valor da base de cálculo do PIS/COFINS não teria que subtrair além do desconto do item o desconto do rateio do cupom. Só para exemplificar, para o quarto item, temos: -<det nItem="4"> -<prod> <cProd>1846882028</cProd> <cEAN>07896006748885</cEAN> <xProd>FEIJAO CAMIL 500G BRANCO</xProd> <NCM>07133329</NCM> <CFOP>5102</CFOP> <uCom>UN</uCom> <qCom>1.0000</qCom> <vUnCom>6.99</vUnCom> <vProd>6.99</vProd> <indRegra>A</indRegra> <vDesc>2.00</vDesc> <vItem>2.02</vItem> <vRatDesc>2.97</vRatDesc> </prod> -<imposto> <vItem12741>0.80</vItem12741> -<ICMS> -<ICMS40> <Orig></Orig> <CST>40</CST> </ICMS40> </ICMS> -<PIS> -<PISAliq> <CST>01</CST> <vBC>4.99</vBC> <pPIS>0.0165</pPIS> <vPIS>0.08</vPIS> </PISAliq> </PIS> -<COFINS> -<COFINSAliq> <CST>01</CST> <vBC>4.99</vBC> <pCOFINS>0.0760</pCOFINS> <vCOFINS>0.38</vCOFINS> </COFINSAliq> </COFINS> </imposto> </det> Anexei também o XML em questão para facilitar melhor o entendimento. Para obter o valor do rateio dos itens após a autenticação do CF-e, estamos efetuando o seguinte procedimento: with CFe.Det do begin //Atualiza o valor de rateio para ficar igual ao do SAT for j := 0 to Count - 1 do begin s := ExecSql('SAT_SINC_RATEIO', VarArrayOf([ IDCupom, Items[j].nItem, Items[j].Prod.vRatDesc, Items[j].Prod.vRatAcr ])); end; end; Gostaríamos da opinião de vocês, de como estão procedendo neste caso, se a nossa observação foi correta. AD35160453485215000106599000063300003527789370.xml