Wess

Bom dia Sergio, o interessante é você consultar um analista contábil pra te ajudar nesse quesito, ele saberá (ou ao menos deveria) responder todos seus questionamentos acerca do assunto com maior exatidão. Há várias regras e situações diferentes para cada empresa, então fica complicado lhe passar como são feitos os cálculos sendo que pode resultar em problemas futuros, ao menos em minha opinião, não é mesmo? Abraço

Atualizamos em nossos clientes e começou a ocorrer em MS também

Mesmo problema em PE, apenas em homologação pelo visto. Vale lembrar que utiliza o servidor do RS lá.

Bom dia, estive passando pelo mesmo erro mas resolvi atualizando TODAS as DLLs do diretório do Integrador em %APPDATA% e utilizando o Integrador 1.6.86. Veja se isso não irá resolver pra você caso ainda não tenha resolvido. Lembrando que pode ser necessário desbloquear a dll para correto funcionamento.

Boa tarde Italo, acredito que o que nosso colega tentou nos passar é que a propriedade IntegralHeight já vem setada como True, e dessa forma a impressão ficava como nas duas primeiras imagens, após setar para False, tal questão foi resolvida. Então presumo que a sugestão seria que essa propriedade viesse de padrão como False, correto? Desculpe-me a intromissão, mas acredito que seja esse o caso.

Bom dia prezados, segue anexo do ACBrNFeServicos.ini com alteração na URL de consulta 2.0 para PB_H, conforme especificado em: URLs consulta ENCAT Aproveitando (acredito estar no mesmo assunto ainda), percebi que nenhuma consulta funciona, ao menos em homologação para PB, nas URLS disponibilizadas pelo ENCAT, e quando consultado o QR Code, apenas direciona para a URL precisando digitar a chave de acesso, e por fim continua retornando "Nenhum registro satisfaz a pesquisa". Alguém mais com esse problema? Grato desde já. ACBrNFeServicos.ini

Concordo que varia de homologador pra homologador apesar da clareza de alguns requisitos, inclusive aconteceu conosco na última homologação. Infelizmente há usuários que optam por emitir tudo em contingência e não se preocupam com as consequências futuras, é uma realidade na qual acredito que o trabalho que podemos fazer é basicamente de orientação, e lógico, não desenvolvendo ferramentas que facilitem tal prática. O ideal para tentar resolver da sonegação, ao meu ver, seria ter que enviar por exemplo, o CNPJ da SH, CNPJ do contribuinte, e CNPJ da contabilidade, ou seja, digamos que sejam detectadas inconsistências em um dos usuários no sentido de sonegação ou algo assim, seria fácil para analisar os contribuintes de determinada SH com possíveis problemas, como o ocorrido há poucos anos com aquela empresa que tinha uma tecla para emitir cupom "frio", onde começa descobrindo em um usuário, porém provavelmente vários outros usuários deviam utilizar desse recurso. Não digo que essa questão iria resolver a sonegação propriamente, mas vejo que seria uma forma efetiva de "punição". Em relação à homologação, comentei pelo fato de que há inúmeros sistemas sem critério nenhum, que simplesmente emitem o cupom e não seguem um padrão, que querendo ou não, acabam prostituindo o mercado e gerando em alguns casos até concorrência desleal, mas com certeza algo que não seja tão "louco" como o credenciamento do PAF, que tem alguns requisitos sem nexo.

Finalmente algum anúncio relacionado, entretanto recuso-me a acreditar que poderão exigir um equipamento específico para transmissão, apoiaria totalmente algum tipo de processo de "homologação", como o que já existe hoje pro PAF, mas burocratizar com outro equipamento (certamente custando um olho da cara) é o fim...

O provedor de Concórdia é o IPM, se não me engano há poucos meses atrás um pessoal de Santa Catarina implementou o provedor IPM no ACBrNFSe, como desenvolvemos uma solução própria aqui na empresa, não sei lhe informar em termos de funcionalidade, mas aparenta estar funcionando corretamente apesar de não seguir padrão ABRASF.

@Suporte Acodi Bom dia, como agora é um url na web e não mais um executável que precisa ser enviado pro dropbox, vou postar por aqui mesmo para outras pessoas já utilizarem caso necessário... http://simuladorposceara.azurewebsites.net/ O funcionamento é igual ao simulador anterior.

Boa tarde @João Paulo Alcântara, primeiro você gera o XML da venda, exatamente como é no SAT, depois você vê se o pagamento é TEF/POS e manda os comandos de acordo com o que tá no Demo do ACBrSAT, os comandos variam se for TEF ou POS, após retornar o status do pagamento como sucesso, você envia a venda, e se a venda for enviada com sucesso fosse envia a resposta fiscal do pagamento. Consulte o Demo do ACBrSAT na aba do MF-e, tem um botão pra cada comando que deve ser enviado, pra entender a ordem de envio como disse anteriormente tem no manual, é só dar um Ctrl+F pela palavra "fluxo". Não to com nenhum XML do pagamento mas no manual tem também o exemplo.

Recomendo a leitura integral do manual: http://www.sefaz.ce.gov.br/content/aplicacao/internet/CFe/arquivos/manual_de_utilizacao_integrador_fiscal_14.pdf Algumas dúvidas já podem ser tiradas ali mesmo, como nosso colega comentou, a principal diferença está em operações TEF e POS, que passam pelo integrador também, e com POS tudo passa pelo servidor da SEFAZ enviando e retornando status dos pagamentos. De resto é só configurar igual o SAT selecionando o modelo "mfe_Integrador_XML" que o ACBrSAT faz o resto pra você.

Acostume-se, webservice do Bloco X funciona quando quer... Eles estão em constante mudança.

está com schemas atualizado e setado no componente pra versão 3.0?

A princípio só falta informar o grupo <ICMSUFDest> por se tratar de operações interestaduais com não contribuinte do ICMS.